> Date: Fri, 3 Feb 2006 12:07:03 +0100
> From: joerg@...

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

Agreed.  Hence the round-robin token passing to avoid contention.


> 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

For short spins, fine.  But when contention is "high", spinning just 
degrades wastefully.


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

*nod*


> [snip example]
>> Or am I missing something?
>
> You are effectively implementing Token Ring :-) There are different

Yes.  You have correctly identified the source of the inspiration. :-) 
It works for token ring...


> mechanisms for passing lock ownership, e.g. compare a classic mutex with
> DragonFly's token primitive. They all have different performance

Hmmmm.  I'll have to look at dfly source again.


> characteristics, but none is free. Trading bus locked operations for

Very true ("none is free").


> round robin operations + spinning is almost always a bad deal though,
> I'd say.

I'm suggesting polling, not spinning.  i.e., assuming that a CPU has 
enough "other threads" to run when it doesn't hold the mutex that thread 
X wants.  (Although if the CPU didn't have other threads to run, would 
it matter if it sat spinning?)

Of course, perhaps the atomic r/m/w instructions (e.g., cmpxchg) aren't 
the bottleneck.


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.