[cpp-threads] atomic operations package

[Matt Hurd]

On 24/08/05, Peter Dimov <pdimov at mmltd.net> wrote:
> Alexander Terekhov wrote:
> > On 8/23/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> 
> >> 1) You make the ordering constraint a run-time parameter, and I make
> >> it a member template parameter.  My guess is that you almost never
> >> want it to be a runtime parameter.
> >
> > It's not really meant to be a run-time parameter. It just takes a bit
> > less characters and is more readable IMO.
> 
> I prefer the "runtime" formulation and not using an atomic<> template
> because this keeps the syntax C-compatible. The atomics should - in my
> opinion - be implemented as compiler intrinsics; these are usually shared
> between the C and C++ compiler.
> 
> The C people would never accept the <> syntax. They hate templates with a
> passion. :-)

I'd hate to see a C++ go back to C only but I agree that C people,
including some who work with me, need <> free code :-)

One suggestion though is to have size based functions at C level and
wrap them in C++ with SFINAE support for size restrictions.  I do this
in my home grown stuff:

e.g. from my gcc_x86_64 implementation header...

    template< typename T = int, typename Enable = void>
    class atomic_op_synch {};

    
    /// \brief      Simple class wrapper for raw atomic functions of 64 bit size
    template< typename T >
    class atomic_op_synch< T, typename boost::enable_if_c< sizeof(T)
== sizeof(long)   >::type >
    {

    /// \brief      Simple class wrapper for raw atomic functions of 32 bit size
    template< typename T >
    class atomic_op_synch< T, typename boost::enable_if_c< sizeof(T)
== sizeof(int) >::type >
    {

Complemented by static asserts for boost::is_integral in the
appropriate methods as there is no need for cas etc to be integral
restricted.

You could either "fall through" to a generic mutex implementation or
assert on sizes not supported natively by the atomic ops on the
platform.  I can see arguments for both approaches.

I do like having the operations wrapped in a type to support generic
code where synch and synch-less ops are choosable.

$0.0002 

matt.
matthurd at acm.org