cvs commit: src/sys/sys mutex.h

[Daniel Eischen]

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