From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-30 07:30:15
From: "Mac Murrett" <mmurrett_at_[hidden]>
> > Why? I don't see anything silly with the idea that an instance of class
> > thread safe.
> My point is that ints are thread-safe; it's operator++ that is not. Given
> this, making another type to do what an int does (hold an integral value)
> thread-safe manor is not useful; it's the incrementation that is being
This looks like a philosophical debate. Obviously "holding an integral
value" - state - cannot be thread safe. It's operations on this state that
are thread safe.
class synchronized_queue; // thread safe
Would you argue that a queue cannot be thread safe - operations can - and
therefore we shouldn't create synchronized_queue but add free functions
synchronized_push and synchronized_pop to the existing queue? This is a
rather novel approach. ;-)
> >> template<class Int>
> >> void increment_atomic(Int &rValue);
> > What are you going to (portably) do with this function? You don't know
> > 'Int', if any, works on the current platform.
> Just specialization such as (for Windows):
> void increment_atomic<long>(long &rValue)
It's possible that I misunderstand your idea.
I meant that, from user point of view, increment_atomic<> is not as useful
as it might seem because, in portable code, you don't know which types
provide an efficient specialization - if any.
Under Windows, it's long; under BeOS it's vint32 (IIRC); under Linux it's
atomic_t (implementation defined, opaque, >= 24 bits.)
That's why atomic_count is necessary - to abstract the platform.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk