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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
