On Fri, Aug 26, 2011 at 2:26 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Aug 26 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
Dave Abrahams wrote: [...]
IIUC, using mutexes in the implementation of C++0x atomics has always been considered an available choice for implementors. ...
Lock-free atomics can not be implemented using mutexes. Lock-free SC atomics need a heavy-weight 'hwsync' on PowerPC/PPC (mutexes don't need 'hwsync').
Thanks for educating me.
Nobody needs atomics implemented using mutexes because locking can be done more efficiently on higher level.
Well, the idea is to allow code using atomics to run at all (if suboptimally) on platforms that don't support hardware atomics for the data type in question.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
I think you are trying to highlight an important point here, and I agree with you (that it is important and needs to be looked into - not that you said that specifically...). The idea in the standard is that atomic<Foo> foo; is suppose to work for any Foo, I think. If Foo is too big to be atomic by the CPU, then a mutex is to be used inside the atomic<>. And that should have the same semantics as atomic<int>. So my first question is, is the above true? Second is whether that is a problem. Note that in:
mi.lock(); i = 1; mi.unlock();
mj.lock(); j = 2; mj.unlock();
can be transformed to
multi_lock(mi, mj); // deadlock free j = 2; i = 1; mi.unlock(); mj.unlock();
There is no "synchronizes with" (standard's wording) because synch-with requires thread 2 to *read* the value written into the atomic by thread 1. We have no reads here - no if statement - so reordering doesn't matter. I don't think the standard disallows the reordering of i and j, even if they are atomics. Tony