> 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.


> Ahem. How do you expect two threads on different CPUs to synchronise
> correctly if no locked bus cycles are involved? It is important to
> distinguish atomic operation and atomic bus locked operations after all
> :-)

What about

 	if (my_id == *mutex_holder) {
 		do_stuff_that_needs_mutex();
 		*mutex_holder = (*mutex_holder + 1) % num_mutex_holders;
 	}

Assuming a coherent cache, I don't see reading *mutex returning a wrong 
"oh, I have the mutex again already" value.  With round-robin "now it's 
your turn" passing the mutex, I don't see a race condition in which 
multiple CPUs each think they hold the mutex a la contention-based mutex 
grabs.

Or am I missing something?


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
________________________________________________________________________
DO NOT send mail to the following addresses:
davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.