cvs commit: src/sys/sys mutex.h

[Jeff Roberson]

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.

Yes it does.  I'm checking a thread that is on the run queue but not
running.  If it holds giant it will hold giant until I drop the sched lock
and schedule it to run.

>
>         if (thread == curthread && mtx_owned(&Giant)) {
>                 ...
>         }
>
> I'm just worried that if this is there someone is going to use it. :(

Yes, I see, this is a valid concern.  I originally had it in sched_ule.c
only but decided that it was ugly to do so.  I could move it back or
manually code the check there.

>
> --
>
> John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
>