Date: Tue, 14 Oct 2003 17:18:19 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-src@FreeBSD.org Subject: RE: cvs commit: src/sys/sys mutex.h Message-ID: <Pine.GSO.4.10.10310141713100.7209-100000@pcnet5.pcnet.com> In-Reply-To: <XFMail.20031014170830.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Oct 2003, John Baldwin wrote:
>
> On 14-Oct-2003 Jeff Roberson wrote:
> > On Tue, 14 Oct 2003, John Baldwin wrote:
> >
> >>
> >> On 12-Oct-2003 Jeff Roberson wrote:
> >> > jeff 2003/10/12 14:02:55 PDT
> >> >
> >> > FreeBSD src repository
> >> >
> >> > Modified files:
> >> > sys/sys mutex.h
> >> > Log:
> >> > - Implement a mtx_ownedby() macro which can be used to determine if a
> >> > particular thread owns a mutex. This cannot be done without races
> >> > unless the thread is curthread.
> >>
> >> This is a very bad idea. What use do you have for this that is not
> >> already handled by mtx_owned() or a mutex assertion?
> >
> > I know it is racy in most contexts. I use it to check to see if a thread
> > on the runq owns giant. Since I have the sched lock it isn't racy but
> > even if it was it wouldn't matter in this case.
>
> sched lock doesn't keep it from being racy. Uncontested acquire and
> releases don't go anywhere near sched lock. Are you checking a
> non-curthread thread pointer? Maybe you could just do it for curthread
> and that would be enough for your heuristic, i.e.
>
> if (thread == curthread && mtx_owned(&Giant)) {
> ...
> }
>
> I'm just worried that if this is there someone is going to use it. :(
Just a thought. If you could assign priorities to mutexes
(like priority ceiling/protect mutexes), threads owning
such mutexes would inherit their priority and the schedulers
wouldn't need to know about who owned specific mutexes.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10310141713100.7209-100000>