
An Introduction to Lock-Free Programming (2012) - bowyakka
http://preshing.com/20120612/an-introduction-to-lock-free-programming/
======
unwind
I ran into this problem last year, that ordinary mutexes were not working out
due to various reasons.

Since I do embedded programming, I looked through the ARM manuals and
documentation, to see what they have on offer.

I ran into the lovely LDREX and STREX instructions, which are just awesome.

It was pretty trivial to rewrite e.g. a custom allocator that used to grab a
mutex, poke its internal freelists, and release the mutex so that it instead
does the poking with _LDREX /STREX_, thus obtaining thread-safety while doing
the actual work it wanted to do. Lock-free programming can be beautiful like
that.

See
[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204f/Cihbghef.html)
for the instruction reference on LDREX/STREX.

------
Patient0
Oh man, now that lock free programming is such a hot topic I am dreading the
code about to be written by people "teaching themselves" about it!

"This algorithm is much faster now that I've used some lock free programming
techniques I just read about!!!"

Code that works correctly on x86 but fails intermittently on another
processor. It's like a nightmare unfolding...

~~~
kabdib
Code that works correctly on that particular programmer's x86 machine, you
mean. "Works great on my PC at home and at work" does not necessary imply
"Works great on the 64 CPU production machine in the datacenter".

This stuff is terrifying.

~~~
preshing
All the more reason to do our best to organize and share correct information
about it.

~~~
Patient0
Yes and at least the article makes it pretty clear just how complicated and
subtle the issues are.

------
fit2rule
I always found this paper to be quite a good introduction to lock-free
techniques:

[http://www.grame.fr/ressources/publications/LockFree.pdf](http://www.grame.fr/ressources/publications/LockFree.pdf)

In the music world, such issues have been solved repeatedly over the years -
seems like a little cross-polination would be a good thing ..

------
taspeotis
Raymond Chen has a pretty practical guide to lock-free algorithms on his blog.

[http://social.msdn.microsoft.com/Search/en-US?query=Lock-
fre...](http://social.msdn.microsoft.com/Search/en-US?query=Lock-
free%20algorithms&beta=0&rn=The+Old+New+Thing&rq=site:blogs.msdn.com/b/oldnewthing/&ac=5)

------
pron
This is perhaps the place to mention that Java 8 has memory-fence intrinsics
(loadFence, storeFence, fullFence in Unsafe)

------
dschiptsov
Does side-effect-free programming with persistent data-structures on share-
nothing, actor-based architecture, in other words Erlang is qualified to be
lock-free?

It seems that Haskell also doesn't exist.)

~~~
lostcolony
While responses have well addressed the deadlock bit of this, and someone else
addressed the side effect free bit, I wantedI wanted to actually make sure you
saw why actors necessarily involve side effects.

    
    
      %Here is a function that rather idiotically takes a process 
      %id, a message, and just sends the message to the process,
      %in Erlang, and then returns the atom 'ok'.
    
      send_message(Pid, Message) ->
        Pid ! Message,
        ok.
    

If this was side effect free, that first line of the function, Pid ! Message,
could safely be removed by the compiler, because it either returns nothing, or
we are doing nothing with the return; either way, if it has no side effects it
is not doing anything. Much like if I were to replace it with something that
obviously does not cause side effects, such as 5 + 7; we're not doing anything
with the 12 that that returns, so why bother calculate it?

But obviously that is not the case; we are expecting the process that Pid
corresponds to to receive that message, and to do something with it.

The very act of sending a message is a side effect.

~~~
dschiptsov
Come on, when people are talking about a code without side effects they meant
so called pure functions, which always produce the same output for the same
input. Message passing is a way of communication which is about "causing
effects" so let's not take it to absurd.

On the other hand, non-networking procedures in Erlang are pure functions, so
they could be safely evaluated in parallel. Its spawned processes are
isolated, they share nothing, not even a common stack, so they could fail and
being restarted without affecting any other code or data.

It is much better to read Armstrong's thesis where he gives outline of the
design of Erlang, hows and whys. It might has a bit ugly syntax, but semantics
are fine.

~~~
lostcolony
My post wasn't a criticism. Just that saying that Erlang is side effect free
(per the OP), is misplaced. Erlang is an insanely pragmatic language that I
use daily, but it very intentionally does not bend over backwards to avoid
side effects, instead allowing them in cases where they make sense.

------
CmonDev
Does unintended infinite message loop count as a dead-lock?

~~~
Rexxar
This is generally called livelock :
[http://en.wikipedia.org/wiki/Deadlock#Livelock](http://en.wikipedia.org/wiki/Deadlock#Livelock)

