Boost logo

Boost :

From: Itay Maman (gtpaw_at_[hidden])
Date: 2001-11-19 07:07:40

--- In boost_at_y..., Jesse Jones <jesjones_at_h...> wrote:
> At 5:18 PM +0200 11/17/01, Peter Dimov wrote:
> >In order to make shared_ptr thread safe (w.r.t. reference counting) we need
> >an atomic_counter type, with the following operations defined:
> >
> >atomic_counter a(n); // n is the initial value, convertible to 'long'
> >++a; // atomic increment, returns the new value (by value, type 'long')
> >--a; // atomic decrement, returns the new value (by value, type 'long')
> >a; // convertible to long, atomic read (to support use_count() and
> The copy semantics need to be ironed out. In the code that was posted
> the Windows version can be copied with no problems. The pthreads
> version can also be copied, but I think bad things will happen
> because the mutex is bit-wise copied. Simply disabling copying may be
> OK.
> -- Jesse

I don't agree with you. I think that atomic_counter's underlying philosophy
is: "it's just like the good old long type, except you need not protect it
when multiple threads are involved". I tried to apply this guideline on the
following piece of code:

atomic_counter a(5);
atomic_counter b(a);

Since the equivalent long code (long a(5); ++a; long b(a); ++b;) yields
a==6, b==7, I belive that most developers expect the atomic_counter code to
generate the same results. Hence, the copy operations (either copy
construction or copy assignment) should be supported, where the
implementation copies the 'other' object's value, but not its mutex.


Boost list run by bdawes at, gregod at, cpdaniel at, john at