

Some light reading on lock-free programming - ingve
http://blogs.msdn.com/b/oldnewthing/archive/2014/11/27/10576382.aspx

======
frozenport
As I understand it, these techniques are oriented towards producer-consumer
queues where there is only 1 producer and only 1 consumer. My software does IO
in this manner. What is confusing is that these schemes don't scale beyond
multiple cores for obvious reasons (1 consumer, 1 producer).

I understand that I can reduce the few ms latency when acquiring a std::mutex,
and perhaps this is valuable for high frequency trading, but I am not sure if
this will improve performance in a palpable manner.

Does anybody have any good uses cases for lock-free programming where the goal
is to scale beyond a single producer-consumer scheme?

~~~
mikeash
Lock free techniques can actually hurt performance compared to mutexes. Their
advantage is predictability. A lock will often be fast and sometimes be really
slow when it has to wait for some other thread. A lock less algorithm runs at
about the same speed no matter what. This is important for realtime tasks such
as audio recording and playback.

~~~
kinetik
My understanding was that a lock free algorithm could still wait for an
unbounded time, and what you're referring to are called wait free algorithms.

~~~
mikeash
You're right, but much depends on how much performance you need and how
critical your realtime performance is. A lock-free algorithm may retry, but it
will likely only retry once or twice. Your running time on any given operation
may occasionally double or triple, but it won't hit you with six order of
magnitudes like might happen with a mutex if it's contended and the thread
that owns a lock takes a page fault or something.

I'd probably want to go wait-free if I was writing software for a Mars lander,
but lock-free is good enough for consumer audio tasks, where mutexes generally
aren't.

