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

[ Available lists | Index of cvs-src | Month of Oct 2007 | Week of 29 Oct 2007 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Julian Elischer <julian@elischer.org>
Date
29 Oct 2007 23:42:04
Subject
Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h
Message-ID
47266992.4020605@elischer.org


[ Hide this part ]
Daniel Eischen wrote:
> On Mon, 29 Oct 2007, Kris Kennaway wrote:
>
>> Daniel Eischen wrote:
>>> 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.
>>
>> Yeah. It looks like Solaris does this. In principle you could do it
>> cheaply with a shared page, I'm not sure what Solaris does.
>
> I think we should add back the thread mailbox for libthr threads.
> I was in favor of keeping the mailbox for libthr, and this might
> be a good use for it.

I have hopes that we can add a per-thread shared page above the stack.
(if asked for)





Elapsed time: 0.176 seconds