Date: Wed, 22 Feb 2006 10:31:06 -0600
From: David Greene < greened@obbligato.org>
Subject: Re: [Boost-users] [statechart] Asynchronous Machines
To: boost-users@lists.boost.org
Message-ID: < 43FC91CA.8060801@obbligato.org>
Content-Type: text/plain; charset=us-ascii

Gottlob Frege wrote:

> Very long answer:  More correctly the problem isn't really 'cache
> coherence' in the traditional meaning of cache coherency  (which is that
> the cache, for your cpu, is consistent with main memory, etc), it is the
> order of memory reads and writes, and Mutex's are guaranteed to do
> whatever is necessary to make sure all queued reads are read before you
> get the mutex lock (ie they force a memory 'acquire' barrier) and they
> make sure all writes are written before the mutex is released (a
> 'release' memory barrier).

I understand what you're saying and agree with you in that that's the
current way hardware and software is implemented in the vast majority
of cases.

However, the concepts of serializing access and maintaining memory
consistency and conherence are orthogonal.  There have been
architectures (in academia, mostly) that require explicit software
cache control, for example.  One would have to include a cache flush in
your examples.  The theory is that by separating concerns the programmer
(or compiler) has more freedom to loosen up implementations based
on weaker requirements of the application, thereby gaining performance.

We're starting to see this much more in HPC systems, for example, where
there are a multitude of synchronization primitives available with
varying semantics that imply performance tradeoffs.  Some machines
cache remote memory (often under software control), others don't.

So I agree with you in the case of the typical machine architecture,
but it won't necessarily hold in the future.


Obviously you understand the problems then.   But I don't understand what you don't agree with - my explanation (obviously missing some details), or whether mutexes will work in the future?

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.

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.


                             -Dave


Thanks,
Tony.