Re: [boost] detail::atomic_counter

From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2001-11-19 10:20:40

From: "Itay Maman" <gtpaw_at_[hidden]>
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
>  > From: "Mattias Flodin" <flodin_at_c...>
>  > > On Sat, 17 Nov 2001, Peter Dimov wrote:
>  > >
>  > > > ++a; // atomic increment, returns the new value (by value, type 'long')
>  > > > --a; // atomic decrement, returns the new value (by value, type 'long')
>  >
>  > As Carl Daniel correctly observed these need not return the new value, only
>  > something that is sign-compatible with it.
>  >
>
> I think a better solution would be to change the implementation of
> operator++() such that it will always return the correct value, which means
> getting rid of the 'special' Win32 version of the class. Nonetheless, we
> can still add two other member functions which will supply the
> increment/decrement functionality implemented via Interlocked* calls.  This
> approach has its drawback  - the mutex is created although it might not be
> needed -  but I think the positive outcome (having ++/-- return the updated
> value) is more substantial.

I don't think that would be an acceptable solution at all.  InterlockedIncrement/Decrement is a user-mode operation,
while acquiring a mutex requires a transition in and out of kernel mode - which is guaranteed to be orders of magnitude
slower.

I agree with Greg Colvin's reply - for boost:shared_ptr, detail::atomic_counter should be lean and mean and provide the
absolute minimum functionality in the most efficient manner.

-cd