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 14:51, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 02:21:34PM +0100, Johnny Billquist wrote:
  >   My initial reaction was that each mutex should have just stored
  >   what ipl it came from, and just restored it back to that when the
  >   mutex was released. That would also allow us to skip the mutex
  >   count in cpu_info, as well as the global saved ipl in cpu_info, but
  >   then I realized that this solution would break if people actually
  >   wrote code like
  >   lock(a)
  >   lock(b)
  >   release(a)
  >   release(b)

...which is very common.

It is? I would have thought (and hoped) that people normally did:

Yes, normally. But not always. Consider something like network interface
queues. Normally, you want to look one queue only. For fast bridging,
ideally, you want to move all packets in bulk, so lock both interfaces
and just process the queue. To allow that you need an inter-lock or some
other way to prevent dead locks. With an interlock, you end up with:

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?


Home | Main Index | Thread Index | Old Index