Re: [boost] Re: detail::atomic_counter

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
X is
> > 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)
in
> thread-safe manor is not useful; it's the incrementation that is being
made
> thread-safe.

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.

Consider:

class queue;
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
which
> > 'Int', if any, works on the current platform.
>
> Just specialization such as (for Windows):
>
> template<>
> void increment_atomic<long>(long &rValue)
> {
>     InterlockedIncrement(&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.