need for another mutex type/flag?

[Robert Watson]

On Mon, 26 Jan 2009, Julian Elischer wrote:

> maybe what I want is to be able to label a lock as "fleeting" By which I 
> mean that the work that would be done while holding this lock would be 
> fleeting (momentary) in nature.
>
> An example f a fleeting lock would be something that gains the lock in order 
> to safely switch two pointers. no malloc is required and nothing is going to 
> take a long time.
>
> locks that are NOT momentary include holding the process list lock while 
> allocating a large buffer (series of them) and dumping the contents of all 
> processes and things like that.
>
> one might almost say that a fleeting lock might be gotten while holding 
> another fleeting lock, but that is pushing it for me..

It was probably clear from my previous e-mail, but just in case it wasn't: we 
already do this.  Mutexes and rwlocks (and rmlocks for that matter) fall into 
the category you call "fleeting", which are allowed to be held over one 
another (subject to lock order), but never over "non-fleeting" locks such as 
sx and lockmgr locks.  This is comparable to the upper/lower half kernel 
concept that existed previously: one is allowed to wait for the other, but not 
vice versa; we allow ithreads to acquire mutexes and rwlocks, but not sx locks 
because that might involve waiting for themselves.

Robert N M Watson
Computer Laboratory
University of Cambridge