Re: [boost] Threads: Atomic Counter

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-30 17:42:32

Hi,
William Kempf wrote:

> Possible interface:

First of all, I'm in favour of such an interface using function on an
opaque type. A possible variation might be the use of traits-like
approach: Since there is only one dimension of variation (the
atomic type) it is not necessary to have the functions as non-member
functions. Thus, something like this might be more in order:

  atomic_traits<atomic_t>::increment(val)
  atomic_traits<atomic_t>::decrement(val)
  ...

> typedef ... atomic_t;
> long increment(atomic_t& dest);
> long decrement(atomic_t& dest);

I can see uses for these three, eg. a referenced counted entity.

> 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);

... but I have no idea what this stuff might be used for. Unless there
are
important uses of the more advanced features, I would prefer to stick
with the bare minimum of functionality which are atomic increment
and decrement functions. If there are usage patterns for the other
features, I would divide them into concepts: I can imagine platforms to
have native support for efficient increment and decrement but not for
the others. Requiring the more advanced features would unnecessarily
burden these atomic integers.

Can you please outline where the other features are necessary?

I assume it is a lost battle to bring up again that this stuff seems to
be at
a too low level of abstraction for now: I still haven't seen the high
level
entities which are implemented using these low-level features...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com