Re: [boost] [interprocess] Atomic ops supports for Alpha processors.

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2007-10-19 07:13:23

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. 
> :-)

Thanks for you input, Peter. That's what I was going to do, hoping it is 
the right thing.

> Last I looked at the various implementations, most of the routines did not 
> provide these guarantees, though.

That's why I (incorrectly) thought that maybe no memory barriers were implied.

> 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.

Yes, I am aware that these don't imply a memory barrier. To the best of my 
knowledge, you have to explicitly state each and every memory barrier on 
Alpha, you will mostly not get an implicit one, especially not when using 
the built-in atomic ops.

> 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.

I think this is the case here.

Thank you very much,
Markus