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 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk