Re: [boost] [atomic] Support for specialized instructions

Subject: Re: [boost] [atomic] Support for specialized instructions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-05-14 14:23:01

On Saturday 23 November 2013 12:37:43 tim wrote:
> hi andrey,
> 
> >> hmmm, i see your points ... however in a way, i'd prefer if this
> >> functionality could be built upon boost.atomic, mainly to keep API
> >> compatibility with std::atomics.
> > 
> > I suppose, the extensions could be made just as functions. What I
> > don't like about this approach is the need to cast pointers to
> > atomic<> to pointers to the underlying integers. We have a few places
> > in Boost.Sync with such code and it really bothers me. Do you think we
> > could at least add a method to get the pointer or reference to the
> > internal storage inside atomic<>?
> 
> yes, this sounds reasonable ...

Resurrecting this discussion...

I gave some thought to this and implementing the operations just as functions 
and not as atomic<> members seems clunky. Users will reasonably ask why they 
are not part of the atomic<> interface. Using atomic<> members on some cases 
and free functions in other looks odd and inconvenient.

So far I can see 3 alternatives:

1. Just add new members to atomic<> and document them as extensions. 
Personally, I'd go with this one.

2. Same as #1 but make an option to disable these extensions at compile time 
(e.g. through a config macro). This will have negative consequences with 
Boost.Sync because it will require these extensions and won't compile without 
them.

3. Leave atomic<> with the standard interface and add its equivalent but with 
extensions. My favorite name is nuclear<>. :) With the new Boost.Atomic design 
it shouldn't cause much code duplication, although it'll be difficult to 
document why there are two similar components in the library. But it's my 
second preference.

What do you think?