Re: mutexes, locks and so on...

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

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:
> lock(a)
> lock(b)
> unlock(b)
> unlock(a)

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:
lock(interlock)
lock(a)
lock(b)
unlock(interlock)

Joerg