From: jpanzer_at_[hidden]
Date: 2000-08-09 18:45:41
William Kempf wrote:
> --- In boost_at_[hidden], jpanzer_at_n... wrote:
> > Jens Maurer wrote:
> >
> > > Dietmar Kuehl wrote:
> > > > <http://www.dietmar-kuehl.de/threads/>
> > >
> > > I've read through the paper.
> > >
> > > For avoiding race conditions, it focuses very much on
> > > mutexes and locks. However, there seems to be a (growing)
> > > set of data structures available which do not require any
> > > locks. For example, a lock-free (yet fully thread-safe)
> > > single-linked list can be achieved when a few atomic CPU
> > > instructions are available (only).
> > >
> > > While this is probably system specific, I wonder whether
> > > such atomic operations can be presented in a portable
> > > interface so as to promote portable implementations of
> > > lock-free data structures.
> >
> > Atomic increment and decrement could be really useful
> > for reference counting.
>
> Don't forget atomic exchange, though it can lead to improper useage
> by someone who doesn't understand concurrency issues.
>
> > However, I worry that not all systems could implement such
> > atomic operations efficiently without some piece of
> > auxiliary storage. Is this an unfounded worry?
>
> 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.
John