Re: [Boost-users] [statechart] Asynchronous Machines

From: David Greene (greened_at_[hidden])
Date: 2006-02-24 10:26:21

Gottlob Frege wrote:

> I'm saying that mutexes will always do whatever is necessary.  For
> example, the pthreads spec tries very hard to describe itself in such a
> way so that it will 'just work' regardless of the underlying problems. 
> And any other mutex/thread library will also work around the problems
> (flushing caches, doing whatever is necessary) or else not be worth using.

I agree that current mutex implementations will do this.  I'm simply
pointing out that the mutex concept (serializing access to a region
of code) is orthogonal to making sure that code is correct in a
memory consistency sense.  The two concepts are obviously used in a
synergistic way.

An example of when this can be useful: if I'm on a NUMA architecture,
I might like to serialize the threads on my local node (which provides
hardware coherence) to make sure updates are ordered but I don't want
to pay the cost of an expensive global sync operation to, for example,
flush caches of remote nodes because I, as the programmer, know that
the data in question is only ever accessed locally.

> P.S. do you have any links to some of the more esoteric synchronization
> primatives?  I've been looking for variations on the typical
> acquire/release barriers as well as systems that don't have CAS, etc. 
> All in the hopes of making at least a start on a useful atomics library.

I'm thinking mostly of some of the things multithreading researchers
have been doing with software cache coherence and the instructions
vector machines like the Cray X1 line have to order references between
the scalar and vector processors for local and remote memory.  There
are lots of variations to tune the operation to just what the programmer
needs, and nothing more.

                              -Dave