On Sep 7, 2006, at 1:23 PM, Jason Thorpe wrote:
[snip]
> Secondly, I want to be very careful about straying from the Solaris  
> API on this stuff.  Solaris's API is nice and minimalist, and they  
> have more than proven that additional baggage in the synchronization  
> APIs is not needed in order to get the job done.
[snip]

This brings up an interesting tangent.  After reading Gregory McGarry's
USENIX paper on RAS[1], I stumbled upon the MCS paper on scalable
locking[2].  Gregory seems to imply that the MCS work would be used
to provide locking mechanisms for SMP systems.

If NetBSD ever migrates to MCS spin locks, how would this be handled
by the Solaris locking API's?  You would somehow have to pass the
qnode used in the acquire call to the release call.  I'm guessing that
you could hide the qnode in some sort of thread local storage, but
that may open up a couple of other interesting problems.

Are you simply planning on staying with the atomic compare exchange
with exponential backoff spin locks that are used by Solaris?

[1]  
http://www.usenix.org/events/usenix03/tech/freenix03/full_papers/ 
mcgarry/mcgarry_html/index.html#mellor-crummey/scott:1991
[2]  
http://www.cs.rice.edu/~johnmc/papers/ 
tocs91.pdf#search=%22%22Algorithms%20for%20scalable%20synchronization%20 
on%20shared-memory%20multiprocessors%22%22

--
David P. Reese, Jr.
daver@siginfo.org