Peter Dimov wrote:
Markus Schöpflin:
Ion Gaztañaga wrote:
Markus Schöpflin escribió:
1) Currently it is not specified whether an atomic operation implies a memory barrier or not. This should be explicitly stated. They should imply a barrier. Since this was an internal header, I haven't documented anything. Now that people is contributing, at least, I should add a comment to the header. OK, I need to add memory barriers to the code then.
You need to know what kind of memory synchronization is implied. Acquire for atomic load, release for atomic store and acquire+release is a reasonably safe bet in situations such as this one where the author isn't quite sure. :-)
Last I looked at the various implementations, most of the routines did not provide these guarantees, though.
Your use of volatile is also a bit suspect. Volatile operations may be atomic without implying an acquire (release) constraint, both for the hardware and for the compiler.
On Alpha, you'll probably need to add a memory barrier after the loads, a memory barrier before the stores, and one before and one after the read/modify/write operations. This would require that the compiler is smart enough to recognize the barrier and not move code across.
OK, I finally got around to add memory barriers to the atomic primitives on Alpha. The corresponding check-in can be found here: http://svn.boost.org/trac/boost/changeset/40967 I hope I got the acquire/release things sorted out correctly. Ion, could you perhaps check if the semantics now match the intended usage? BTW, I added a copyright note to the top of the file, IIUC I'm required to do this. If not, feel free to remove it again. Regards, Markus