Re: Threads: Atomic Counter

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-31 09:08:13

--- In boost_at_[hidden], "Bill Wade" <bill.wade_at_s...> wrote:
> Note that if the underlying system doesn't have built in support 
for all of
> your operations, you will likely want to associate some other 
object (a
> mutex) with the counter, meaning that atomic_t won't be a scalar 
type
> anyway.

That's why we must define an atomic_t and not just methods that take 
a long.  I didn't forget this. ;)
 
> This leads to an interesting design question.  If the underlying 
system has
> good support for read,write and increment, but not add or exchange, 
should
> you make the class with the smaller interface available?

Read/write *are* exchange.  An exchange function bundles the two 
concepts into one.  I honestly don't believe you'll find an 
implementation that supports atomic operations that doesn't support 
exchange, increment and decrement.  Add and the CompareExchange are 
less likely.  I'd hate to lose Add especially, but it is something 
that needs discussed.

>  Note that if you
> end up using a mutex for add, you probably need to use the same 
mutex for
> increment, losing the opportunity to do a "fast" increment.

Possibly, possibly not.  This is really a machine architecture 
problem and not an available library problem.  The atomic operations 
can be written in assembly on a lot of architectures.  The true 
question is whether or not the operations are missing within the 
machine code for the platform and whether in those cases a Mutex is 
considered too slow for our needs.

It's a good point to bring up, though.

Bill Kempf