tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Bug in mutex_owned() ?
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
Home |
Main Index |
Thread Index |
Old Index