[zeromq-dev] atomic ops

[Luca Fascione]

On 09/02/12 19:19, john skaller wrote:
> I won't disagree. I always had trouble with the concept. But I think
> lock-free basically means not using a mutual exclusion lock.

Right. No, I'm afraid it doesn't. What you're describing is occasionally 
called "lock-less", but shouldn't be called lock-free.
Lock-free is a fundamental construct in multiprocessor/multithreaded 
programming. It's the guarantee that at least one part of your process 
as a whole will eventually make progress, in a mathematical sense, 
though. Regrettably it has nothing to do with Critical Sections...
The expression predates mutex objects a bit.

Indeed a lock free algorithm won't have a mutex, but that fact in 
isolation won't guarantee that the algorithm is lock free.

But, yeah, I digress. It has become a bit academic at this point...

More to the point, I think those adds need to be guarded with memory 
fences (MFENCE and friends) to make them work. I'm foggy on the details, 
there's a web page from a DB2 guys that explains the story well enough. 
Fact is that if there is no fence instruction reordering on the 
processor may break the code. TBB has some mentions of acquire/release 
semantics for their atomic integer which I believe has to do with this 
fencing stuff here.

Luca

-- 
Luca Fascione
Rendering Research Lead - Weta Digital
Phone:  +64  4 909 6870 (x6870)
Mobile: +64 21 0764 862