Boost logo

Boost :

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2007-11-09 09:30:36

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:

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at