need for another mutex type/flag?

[Julian Elischer]

Kip Macy wrote:
> The adaptive spinning of regular mutexes already satisfies your need
> for "short" hold. You might wish to add a thread flag used when
> INVARIANTS is enabled that is set when a leaf mutex is acquired and
> checked on all mutex acquisitions.

ummm that was what I was asking for.. an official designation of a 
'leaf' mutex...

> 
> -Kip
> 
> On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian at elischer.org> wrote:
>> Currently we have:
>> spin locks..
>> you really don't want to hold these for
>> any time at all, and this is enforced to some extent in the waiter.
>>
>> regular mutexes..
>> You can hold these for as long as you want but teh shorter
>> the better and you can't sleep when holding them. The
>> "shortness" of the time of holding the mutex is not enforced.
>>
>> "Sleeps" (including sx-locks and friends)
>>  You may hold these or be descheduled for really long periods of time.
>>
>>
>> Now it occurs to me that there is a subclass of regular mutexes,
>> usage, which is where you want to use a mutex to guard some small
>> but critical structure, and that you know that access to that structure will
>> be quick, and that you can guarantee that you will
>> not acquire any other locks (which could introduce unknown delay)
>> while hoding the lock.
>>
>> One way of thinking about this is that this lock would always be
>> a leaf node on the tree of lock orders.
>> I would like to be able to add a flag to a mutex
>> that tags it as a 'leaf' mutex. As a result it would be illegal
>> to take any other mutex while holding a leaf mutex. Somewhat
>> similar to the way that it is illegal to take aregular
>> mutex while holding a spin mutex..
>>
>>
>> In netgraph I have a stipulation that is hard to specify which
>> is that  you MAY take a mutex in a netgraph node if you can guarantee
>> that the mutex WILL be satisfied very quickly, but it'd
>> be nice to be able to specify "you may only take 'leaf' mutexes within an
>> netgraph node".
>>
>>
>> thoughts? (especially from jhb and other locking types).
>>
>>
>> _______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>>