Re: [boost] Threads: Atomic Counter

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-08-30 17:35:02

This one is necessary, but tough.  On platforms which don't
have the necessary instructions to do one of these operations
atomically without a mutex they will be expensive, so I
would lean more towards the minimal useful subset that is
doable (often in only in assembly) on most machines without a
mutex.

For example, after an increment or decrement you may not have
atomic access to the new value, but only to a condition code
that tells you whether it is zero.  So it might be better to
return a bool from increment and decrement rather than force
a slower implementation.

From: William Kempf <sirwillard_at_[hidden]>
> Well, the discussion on the Mutex and ConditionVariable is winding 
> down.  Though we aren't done there, I think it's still appropriate to 
> now move on to the next topic.  So, I'll start the ball rolling by 
> discussing atomic counters.
> 
> Atomic counters are integral types that can be manipulated through 
> atomic functions, functions gauranteed to execute from start to end 
> with out fear of pre-emption causing corruption.  Many platforms have 
> native operations that allow atomic operations on native integral 
> types, but we can't rely on this being the case.  So, we need a type 
> other than the built in integral types that we can build the 
> necessary synchronization into for platforms with out such atomic 
> operations.
> 
> The first question that comes to my mind is, should the atomic type 
> be a class with member functions, or an opaque type that's 
> implementation defined (like time_t).  The opaque type approach is 
> more suitable for C libraries than C++ libraries, but the idea still 
> appeals to me.  With this approach the atomic operations would be 
> stand alone functions.  With the more traditional C++ approach the 
> operations would (likely) be member functions.
> 
> If we use a C++ class we'll need to consider supporting a full range 
> of integer arithematic.  Most atomic counter classes I've seen in 
> other libraries do this.  However, I'm personally against this!  With 
> built in operators the programmer is tempted to do something like the 
> following:
> 
> atomic_counter c = 5;
> atomic_counter c2 = 5;
> c = c + c2 + 10;
> 
> The result here may not be the expected 20 since another thread may 
> interrupt between operator calls.  For some psychological reason this 
> is less likely to occur with function calls.  Most programmers 
> immediately comprehend that they may be interrupted between function 
> calls while they might not make the same correlation with operator 
> calls.
> 
> I think the Win32 API provides most of the atomic operations we'd 
> want.  They are:
>
> Increment - Increments the counter by one.
> Decrement - Decrements the counter by one.
> Add - Adds an integral value to the counter (so subtraction is 
> supported by passing a negative integral value).
> Exchange - Exchanges the counter with an integral value (or vice 
> versa).
> CompareExchange - Compares the counter with an integral value and if 
> not equal exchanges with another integral value.
> 
> Multiplication and division aren't supported, but I don't think this 
> is something that needs support.  Atomic counters aren't normally 
> used for arithematic types, but instead are usually used for 
> reference counting and tracking of flags.
> 
> Possible interface:
> 
> typedef ... atomic_t;
> long increment(atomic_t& dest);
> long decrement(atomic_t& dest);
> long add(atomic_t& dest, long value);
> long add(atomic_t& dest, const atomic_t& value);
> long exchange(atomic_t& dest, long value);
> long exchange(long& value, const atomic_t& value); // Note 1
> long compare_exchange(atomic_t& dest, long compare, long value);
> 
> // Note 1: only needed if atomic_t isn't a long
> 
> Very little thought has gone into this.  I'm just brainstorming in 
> order to open up discussion on this topic.
> 
> 
> 
> 
>