On Thu, Feb 02, 2006 at 06:16:30PM +0000, Edward B. DREGER wrote:
> >Date: Thu, 2 Feb 2006 04:15:42 +0100
> >From: joerg@...
> 
> >It depends *very* strongly which mechanisms you use. If all you need and
> >want is a block mutex, you ultimately have to call the kernel for
> >synchronistation anyway -- both in forking and 1:1 threading.
> 
> Not necessarily.  Store the mutex in a SHM segment, then perform the 
> mutex operations entirely in userland.

Pure spinning is not an option for efficiency, esp. if the number of
threads/prcoesses is larger than the number of CPUs and the blocking
conditions can hold for more than one time slice.

Most mutex implementations are at least somewhat adaptive, if the
environment allows it. E.g. it spins a number of times trying to get
hold of the mutex, afterwards it tells the kernel to block on it. This
needs some care for the exit case as well, but is possible to implement.
But once again, MT vs. MP doesn't make any difference here.

[snip example]
> Or am I missing something?

You are effectively implementing Token Ring :-) There are different
mechanisms for passing lock ownership, e.g. compare a classic mutex with
DragonFly's token primitive. They all have different performance
characteristics, but none is free. Trading bus locked operations for
round robin operations + spinning is almost always a bad deal though,
I'd say.

Joerg