Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Oct 2007 18:11:29 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        Kris Kennaway <kris@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h
Message-ID:  <Pine.GSO.4.64.0710291808160.19572@sea.ntplx.net>
In-Reply-To: <4726597A.6000004@FreeBSD.org>
References:  <200710292101.l9TL1mAE049561@repoman.freebsd.org> <Pine.GSO.4.64.0710291712100.19572@sea.ntplx.net> <472650BF.5060706@FreeBSD.org> <Pine.GSO.4.64.0710291732090.19572@sea.ntplx.net> <4726560F.5050804@FreeBSD.org> <Pine.GSO.4.64.0710291756360.19572@sea.ntplx.net> <4726597A.6000004@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Oct 2007, Kris Kennaway wrote:

> 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 am not familiar with that code, can you point me to the change that removed 
> it?

This was when David revised libthr, so it never really had a
mailbox.  libkse has the mailbox, and I would have preferred
keeping a similar interface for libthr (specifying it on
thr_create(2)).  You can look at how it works for KSE as an
example.

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0710291808160.19572>