LT> These are platform specific details. We will use whatever the
LT> platform/OS provides. In the source code its a LOCK() UNLOCK() pair.
LT> The LOCK() can be any atomic operation and doesn't need to call the
LT> kernel, if the lock is aquired.
if it doesn't call the kernel, how can a thread be blocked?
LT> I wrote, *if* the lock is aquired. That's AFAIK the fast path of a futex
LT> or of the described Win32 behavior. The slow path is always a kernel
LT> call (or a some rounds spinning before ...)
LT> But anyway, we don't reinvent these locking primitives.
ok, i missed the 'if' there. :)
that could be workable and might be faster. it does mean that locks are
two step as well, user space test/set and fallback to kernel lock. we
can do what nigel said and wrap the test/set in macros and use assembler
to get at it on platforms that have it
This is probably already done inside of pthread (and Win32) locking implementations--a check in userspace before a kernel call. It's also important to remember that it's not a two-step process most of the time, since most of the locking we are taking about is likely to be uncontested (ie, the lock acquisition will succeed most of the time, and no blocking will be needed). If we _do_ have major lock contention in our internal locking, those will be areas calling for a redesign.
JEff
