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

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2007-10-19 04:33:16

Ion Gaztañaga wrote:
> Markus Schöpflin escribió:
>> Hello,
>>
>> attached patch introduces support for the atomic ops needed by 
>> interprocess on Tru64/CXX/Alpha. It currently misses support for atomic 
>> add and sub, but those are not used right now.
> 
> Applied in SVN. If I've introduced any error (I've applied the patch by 
> hand), please feel free to commit a fix.
> 
>> There are a few issues I would like to raise regarding the atomic 
>> operations:
>>
>> 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.

>> 2) atomic_sub32 does not return the old value, but atomic_add32 does. 
>> This seems inconsistent to me.
> 
> I agree. Nevertheless, I think atomic_add32 is enough since atomic_sub32 
> can be implemented as with atomic_add32(boost::uint32(-val)). I'm 
> planning on removing some unused operations, to maybe is time to remove 
> atomic_add32/atomic_sub32.

The interface for add32 takes unsigned integers, so you can't just call 
add_32(-val). But as both operations are unused, it's probably best to 
remove them.

>> 3) Has the use of the low level atomic ops API as proposed in WG21/N2047 
>> (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html) 
>> been considered. If yes, why has it been rejected? If no, would it makes 
>> sense to use this API?
> 
> If you are talking about using N2047 in Interprocess, I always thought 
> that boost/interprocess/detail/atomic.hpp was a temporary solution until 
> an atomic operations library was developed. I just needed some basic 
> operations and a full barriers were good enough for me. Developing an 
> atomic operations library is rocket science for me.

Understood.

>> 4) Is there a need for an atomic ops boost library? I seem to remember 
>> that other libraries need atomic ops as well.
> 
> Definitely yes. I'm still surprised that there are no atomic operations 
> on Boost apart from shared_ptr internals. I think we have people with 
> deep knowledge on atomic operations, so let's put some pressure on the 
> mailing list...

Probably not the best time right now, being close to the next release, but 
otherwise I agree with you.

Regards,
Markus