[zeromq-dev] atomic ops
lukes at wetafx.co.nz
Thu Feb 9 07:46:38 CET 2012
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.
Rendering Research Lead - Weta Digital
Phone: +64 4 909 6870 (x6870)
Mobile: +64 21 0764 862
More information about the zeromq-dev