on Wed Aug 24 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
Dave Abrahams wrote: [...]
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();
and thus result in reodering i = 1 and j = 2.
With C++11 default atomics (SC) for i and j such reodering is prohibited.
As it is with C++11 mutexes, IIUC.
Mutexes need only *acquire-release* semantics coupled with RMW(s) to result in *SC* for associated race-free data, as observed by another thread(s).
I think I know that...
C++11 default atomics are *SC* without mutexes (lockfree and all that stuff)... *SC* is more expansive than *acquire-release* in terms of sync
...and I think I know that...
on platforms such as:
If you have contrary evidence, please point to it.
http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html (PowerPC)
I mean:
Load SC: hwsync; ld; cmp; bc; isync Store SC: hwsync; st
alternative mappings:
Load SC: ld; hwsync Store SC: lwsync; st; hwsync
Note that *acquire-release* does NOT need *hw*sync:
Load Acquire: ld; cmp; bc; isync Store Release: lwsync; st
I'm pretty sure I did't know that part, but I don't yet see what it has to do with your assertion. IIUC, using mutexes in the implementation of C++0x atomics has always been considered an available choice for implementors. If that reordering were allowed for mutexes, wouldn't that weaken the semantics of atomics? -- Dave Abrahams BoostPro Computing http://www.boostpro.com