cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h

[Daniel Eischen]

On Mon, 29 Oct 2007, Kris Kennaway wrote:

> Daniel Eischen wrote:
>> 
>> The libkse implementation already spins for a bit.  The default
>> number of spins is 500.
>
> OK, cool.
>
>> I'm not sure that another mutex type is warranted, the default
>> mutex implementation should be adaptive I think.
>
> The point being that certain existing applications already know about this 
> mutex name and will use it automatically when it exists.
>
> I am a bit wary of making this the default type though.  The algorithm is a 
> pessimization when the conditions described above are not true.

I agree, and it applies a little to the KSE approach also.
Spinning is mostly a hack for not being able to tell in
userland if a thread is swapped in/out or is on another
CPU.  If you solve that problem, then you can make the
default mutex adaptive.

In KSE, it was a little easier, because we could set a flag in
the thread's mailbox to tell the scheduler that it was in a
critical region, so no other thread from that process
would be run on that KSE until it was out of the critical
region.  Low-level locks in KSE were always taken while
in these critical regions, so if it tried to acquire a lock
that was already taken, it knew it must be running on a
different KSE (and in theory a different CPU, although
binding KSEs to CPUs was never implemented).  Even with
this approach, libkse still didn't know if the thread
was active or swapped out on another CPU.  It would have
been cool to have the scheduler indicate this with a
flag in the thread's mailbox.

-- 
DE