Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-10 08:41:58


--- In boost_at_[hidden], jpanzer_at_n... wrote:
> William Kempf wrote:
> > An "atomic counter" can be implemented on all systems for which a
> > mutex can be implemented. If the system doesn't support the
> > underlying primitives you simply build them by using a mutex. No
> > where near as efficient, but it solves the problem of portability.
>
> This is my worry. I don't see any obvious way around having to
> use a single, global mutex to implement operations like
> "atomic_incr(i)", where the caller does not supply a mutex.
> For many applications of atomic operations, I think this
> would be unacceptable overhead. The client code would need
> to be redesigned to create more fine-grained parallelism, probably
> by creating and using multiple mutexes. In which case the
> portable atomic operation interface isn't helping much.

You aren't talking about quite the same thing that I am. You're
addressing this as using a primitive integral type in a function call.

int i;
atomic_incr(i);

This would require either primitive support for atomic operations
(something which may not be possible on all platforms) or, as you
suggested, a single global mutex used for all calls to the atomic
operations.

What I suggested was an "atomic counter". Simple example:

class atomic_counter
{
public:
   explicit atomic_counter(int val=0);

   int get_value();
   int set_value(int val);
   int increment();
   int decrement();

private:
   int _value;
#ifndef BOOST_HAS_ATOMIC_OPS
   mutex _mx;
#endif
};

I've not fleshed this out to the point of being useful, but it's
enough to convey the concept. The atomic operations are defined with
atomic primitives if they exist, otherwise internal synchronization
is controlled via a mutex. It's not as good as full support for
atomic operations, but it works in nearly every place that the atomic
operations would be used and is portable to all platforms.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk