tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mutexes, locks and so on...



On 11/12/10 15:07, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 02:58:16PM +0100, Johnny Billquist wrote:
lock(interlock)
lock(a)
lock(b)
unlock(interlock)

I realized I'm getting sloppy here. When I say locks in this
context, I'm actually talking about spin mutexes. Simple locks are a
different story, since they don't fool with IPL levels at all.

Also, for spin mutexes I'm not sure the above scenario would make
sense. Since, if they were spin mutexes, assuming once process did
that, and then another did it, the second process would stop at
lock(a), with interlock held. I would assume interlock would be at a
very high ipl, so the first process would never continue, and unlock
a and b, so we'd be in a deadlock.
And if the idea is that we'd stay at the high ipl in the first
process, that more or less would mean that we essentially holds on
to interlock, so why unlock it?

If you have a UP system, it doesn't make a difference, yes. For SMP, it
does. It allows other CPUs to continue if other interface, even using
the interlock.

Hmm. You might have a point there. Need to think a bit more about it, but I wonder under which circumstance such a construct might be reasonable in the real world. I mean, would you expect a and b to also be spinlocks in this case? I can see grabbing them both atomically might be a nice thing, but if it's to avoid deadlocking, then there are other (better) ways of doing it.

Oh well, like I said, I'd need to think more if this really is a reasonable thing. :-)

        Johnny


Home | Main Index | Thread Index | Old Index