Re: Bug in mutex_owned() ?

[Hans Petter Selasky <hselasky%c2i.net@localhost>]

On Sunday 25 October 2009 19:28:18 Mindaugas Rasiukevicius wrote:
> Hans Petter Selasky <hselasky%c2i.net@localhost> wrote:
> > > It can test that current CPU holds the lock, but it wont buy you
> > > anything, because if your context (thus CPU) is not holding the lock,
> > > then such test is useless - lock state is free to change (e.g. other
> > > CPUs can release or acquire your lock at the same time).
> >
> > The test is in-fact useful for more than assertions. Like when
> > implementing statements to avoid recursive locking. I disagree that it is
> > purely bad design that leads one to require mutex_owned() checks.
>

Hi,

> How are you using it?

I'm using it everywhere, basically. After looking closer at the implementation 
I see that I cannot use spin-locks for what I am using it ...

For example I see I need to make a separate thread for interrupts and 
callouts, because i cannot mutex_enter() in there with IPL_NONE. Hopefully 
that will solve my problems.

What I find strange is that by default no warning is posted if I try to 
mutex_enter() an IPL_NONE initialised mutex from a PCI interrupt handler.

> "Avoiding" should mean "not requiring".  If mutex_owned() is used to avoid
> locking of already held lock, then you are basically implementing the idea
> of recursive mutex, just in a higher layer.  In other words, using of such
> checks to make locking decisions have pretty much the same negative effects
> of recursive locking.

--HPS