Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Jan 2009 01:28:38 -0800
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        arch@freebsd.org, Julian Elischer <julian@elischer.org>, Kip Macy <kmacy@freebsd.org>
Subject:   Re: need for another mutex type/flag?
Message-ID:  <20090125092838.GC87077@elvis.mu.org>
In-Reply-To: <20090124224716.X983@desktop>
References:  <497BA91D.805@elischer.org> <3c1674c90901241956j244ed067p7ff4df5454beba82@mail.gmail.com> <497C235E.5090807@elischer.org> <20090124224716.X983@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@jroberson.net> [090125 01:21] wrote:
> On Sun, 25 Jan 2009, Julian Elischer wrote:
> 
> >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...
> 
> It'd be much easier to add the flag as a mtx_init() flag and have witness 
> check it.  It'd only take 15 minutes to do properly.
> 
> What is the case you have where you can not acquire non leaf mutexes?

Jeff, I think that Julian really wants to prevent a sleep inside
his context.  Right now, I think we only check for mutexes held
before a sleep that arne't sleepable.  It might make sense to allow
one to just mark a thread non-sleepable even though no mutex is
held.

Julian, is that right?

> 
> Thanks,
> Jeff
> 
> >
> >>
> >>-Kip
> >>
> >>On Sat, Jan 24, 2009 at 3:49 PM, Julian Elischer <julian@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@freebsd.org mailing list
> >>>http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> >>>To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
> >>>
> >
> >_______________________________________________
> >freebsd-arch@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
> >
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

-- 
- Alfred Perlstein



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