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
> mutex) with the counter, meaning that atomic_t won't be a scalar
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
> good support for read,write and increment, but not add or exchange,
> 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
> 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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk