Alexander Terekhov <terekhov@web.de> writes:
Anthony Williams wrote: [...]
http://www.justsoftwaresolutions.co.uk/cplusplus/cplusplus-standards-committ...
Thanks for the summary.
Starting with basics, I've read
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2748.html (N2748: Strong Compare and Exchange)
and I think that n2748's compare_exchange_strong() is very under-specified regarding intended x86's CAS incarnation:
E.g. (pseudo code, sorry for eventual bugs)
do { loaded = load_reserved(); if (loaded != expected) { expected = loaded; return false; } } while (!store_conditional(desired)); return true;
vs.
do { loaded = load_reserved(); stored = (result = (loaded == expected)) ? desired : loaded; } while (!store_conditional(stored)); return expected = loaded, result;
The first one may result in 'dangling' reservations (which is OK) and doesn't attempt to perform a store on comparison failure.
The second one is most closely matching x86's CAS (it always performs a store, even in failure case).
The first one provides better performance in failure case but can not be used as a 'fake' RMW to achieve 'write atomicity' visibility on platforms without write atomicity (like Power).
In writing this up for the committee, it occurred to me that if you specify memory_order_release for failure then that may require the second implementation in order to get the required store. Also, the compare_exchange functions are specified as being "atomic RMW operations", so that implies a store to me. Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK