From: Mattias Flodin (flodin_at_[hidden])
Date: 2001-11-17 10:50:12
On Sat, 17 Nov 2001, 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 unique())
>
> See below for a proposed implementation.
>
> Comments are welcome.
Pretty nice. Two questions: Firstly is there a rationale for not
allowing / implementing postfix increment and decrement? Secondly, I'm
just curious, why are you adding zero to _MSC_VER?
Since the required range of a counter may vary, perhaps it is not
unreasonable to parameterize this class with respect to the counter type.
I realize that this is not necessary with atomic_counter being in Thread's
detail namespace, but I don't see why a type such as this shouldn't be
exposed for the library user to benefit from.
Speaking of atomic access, I've been thinking about the sig_atomic_t type
discussed earlier. Wouldn't it be useful with an portable atomic-access
integer type? In systems where sig_atomic_t exists as an atomic type, this
could be simply a typedef. In win32, accesses to 32-bit aligned integers
are guaranteed atomic, so there it could be just typedef int atomic_int.
In other systems where no atomic type is available this would need to fall
back on a mutex. The type could perhaps be declared somewhere in
Boost.Threads, or in Boost.Integer.
/Mattias
-- Mattias Flodin <flodin_at_[hidden]> "A good thing about C++ is that only Room D418 friends can access your private parts" Department of Computing Science Umeå University S-901 87 Umeå, Sweden Note: Any opinions expressed in this mail are personal, and do not necessarily reflect an official standpoint of Umeå University.