As anyone proposed something similar? Do you is think is worth the
addition to the standard library?

class AtomicInt {
public:
 typedef /* implementation_defined */ int_type;

 //implementation defined
 static void Increment(int_type volatile* dst);
 static void Decrement(int_type volatile* dst);
 static void Add(int_type volatile* dst, int_type v);
 static int_type ExchangeAdd(int_type volatile* dst, int_type v);
 static int_type Exchange(int_type volatile* dst, int_type v);
 static int_type CompareExchange(int_type volatile* dst, int_type v,
int_type cmp);

public:
 AtomicInt() { }
 AtomicInt(int_type v): _value(v) { }

 void add(int_type v) { Add(&_value, v); }
 void sub(int_type v) { Add(&_value, -v); }
 void inc(int_type v) { Increment(&_value); }
 void dec(int_type v) { Decrement(&_value); }
 int_type xchg(int_type v) { return Exchange(&_value, v); }
 int_type cmpxchg(int_type v, int_type cmp) { return
CompareExchange(&_value, v, cmp); }

 operator int_type() const { return _value; }
 int_type operator=(int_type v) { return _value = v; }

 int_type operator+=(int_type v) { return ExchangeAdd(&_value, v) + v;
}
 int_type operator-=(int_type v) { return ExchangeAdd(&_value, -v) - v;
}

 int_type operator++() { return ExchangeAdd(&_value, 1) + 1; }
 int_type operator--() { return ExchangeAdd(&_value, -1) - 1; }
 int_type operator++(int) { return ExchangeAdd(&_value, 1); }
 int_type operator--(int) { return ExchangeAdd(&_value, -1); }

 bool operator!() const { return !_value; }
 bool operator!=(volatile int_type v) const  { return (_value != v); }
 bool operator==(volatile int_type v) const { return (_value == v); }
 bool operator<=(volatile int_type v) const { return (_value <= v); }
 bool operator>=(volatile int_type v) const { return (_value >= v); }
 bool operator<(volatile int_type v) const { return (_value < v); }
 bool operator>(volatile int_type v) const { return (_value > v); }

private:
 int_type volatile _value;

};

template<class T> class AtomicPtr {
public:
 //implementation defined
 static T* ExchangeAdd(T* volatile* dst, T* v);
 static T* Exchange(T* volatile* dst, T* v);
 static T* CompareExchange(T* volatile* dst, T* v, T* cmp);

public:
 AtomicPtr() { }
 AtomicPtr(T* p): _ptr(p) { }

 T* xchg(T* v) { return Exchange(&_ptr, v); }
 T* cmpxchg(T* v, T* cmp) { return CompareExchange(&_ptr, v, cmp); }

 operator T*() const { return _ptr; }
 T* operator=(T* p) { return _ptr = p; }
 T* operator->() const { return _ptr; }

 T* operator++() { return ExchangeAdd(&_ptr, sizeof(T)) + sizeof(T); }
 T* operator--() { return ExchangeAdd(&_ptr, -sizeof(T)) - sizeof(T); }
 T* operator++(int) { return ExchangeAdd(&_ptr, sizeof(T)); }
 T* operator--(int) { return ExchangeAdd(&_ptr, -sizeof(T)); }

 bool operator!() const { return !_ptr; }
 bool operator!=(volatile T* p) const  { return (_ptr != p); }
 bool operator==(volatile T* p) const { return (_ptr == p); }
 bool operator<=(volatile T* p) const { return (_ptr <= p); }
 bool operator>=(volatile T* p) const { return (_ptr >= p); }
 bool operator<(volatile T* p) const { return (_ptr < p); }
 bool operator>(volatile T* p) const { return (_ptr > p); }

private:
 T* volatile _ptr;

};

PS: Many people have asked support for multithreading in the language
but is my opinion that we only need support in the core language for
thread local storage (witch does not concern me because today compilers
already support this) and peer thread guaranteed exception handling
(also supported I think), the rest is library implementation details
(threads, mutexs, locks, etc...).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

BS wrote:
> As anyone proposed something similar? Do you is think is worth the
> addition to the standard library?
>
> class AtomicInt {
> public:
>  typedef /* implementation_defined */ int_type;
>
>  //implementation defined
>  static void Increment(int_type volatile* dst);
>  static void Decrement(int_type volatile* dst);
>  static void Add(int_type volatile* dst, int_type v);

    There's a lobby that insists on compare-and-swap, rather
than atomic operations.  We'll undoubtedly hear from them
shortly.  Whether atomic operations or compare and swap
are more efficient on multiprocessors depends strongly
on how the underlying hardware handles cache consistency.

    The QNX world uses a consistent, portable set of
atomic operations (atomic_inc, atomic_dec, etc.) and
has good results with them.  If you're looking at locking
primitives, take a look at how QNX addresses these issues.
In the Windows and Linux worlds, user-level locking usually requires a
system call, but in the QNX world, there's a system call
only when a thread blocks.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

BS ha scritto:
> As anyone proposed something similar? Do you is think is worth the
> addition to the standard library?

If I may suggest, you should propose this for the Boost libraries
<http://boost.org>, maybe as an addition to the Boost.Thread library.
Once it has been peer-reviewed and (hopefully) accepted there, a
proposal for standardization would be much easier to support.

Just my opinion,

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> BS wrote:
> > As anyone proposed something similar? Do you is think is worth the
> > addition to the standard library?
> >
> > class AtomicInt {
> > public:
> >  typedef /* implementation_defined */ int_type;
> >
> >  //implementation defined
> >  static void Increment(int_type volatile* dst);
> >  static void Decrement(int_type volatile* dst);
> >  static void Add(int_type volatile* dst, int_type v);
>
>     There's a lobby that insists on compare-and-swap, rather
> than atomic operations.  We'll undoubtedly hear from them
> shortly.  Whether atomic operations or compare and swap
> are more efficient on multiprocessors depends strongly
> on how the underlying hardware handles cache consistency.

The hardware implementation or the ISA are irrelevant to
performance anyway.  What matters is the the very fact that
there's a (contended) shared piece of memory.

>     The QNX world uses a consistent, portable set of
> atomic operations (atomic_inc, atomic_dec, etc.) and
> has good results with them.  If you're looking at locking
> primitives, take a look at how QNX addresses these issues.
> In the Windows and Linux worlds, user-level locking usually requires a
> system call, but in the QNX world, there's a system call
> only when a thread blocks.

No idea for Windows, but on GNU/Linux non-contended operation has been
purely user-space for several years now.

~velco

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2006-02-09, BS <nayart3@gmail.com> wrote:
> As anyone proposed something similar?

Not concretely, no, but there is a draft proposal at
<http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/atomics.h.txt>.

> Do you is think is worth the addition to the standard library?

Certainly - but there are many architectures that do not support all
the operations you have included, which make it hard to standardise
a useful interface.

<snip>
> PS: Many people have asked support for multithreading in the language
> but is my opinion that we only need support in the core language for
> thread local storage (witch does not concern me because today compilers
> already support this) and peer thread guaranteed exception handling
> (also supported I think), the rest is library implementation details
> (threads, mutexs, locks, etc...).

There may not be a need for any new *syntax* for threads etc., but
there is a need to sort out the semantics of the language in a
multithreaded context.  See
<http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html>.

--
Ben Hutchings
The world is coming to an end. Please log off.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]