Hi...

We're currently designing a Resource Manager that offers two devices to the user.
Each of the devices can be opened by multiple processes.
The data pumped into the devices is passed down via a serial bus.

The idea is that the user locks his device, does some operations, then unlocks it again.
In case the device is already locked, the lock() syscall blocks until the lock is aquired (or it returns right away, in 
case the device was opened non-blocking).

Now if the device is locked, another client who tries to lock it will block. Now if you try to stop that blocked client,
 for example via Ctrl-C, it won't work, because it is blocked in the MsgSend inside the call responsible for locking the
 device. So we need to implement an unblock handler in the Resource Manager.

Currently the blocking is implemented via waiting on a condvar in the ResMgr. Obviously, this is a problem for 
implementing an unblock handler.

How is this usually solved? Obviously I want a performant solution, i.e. the client should really block, not repeatedly 
poll. I could do the blocking in the ResMgr by means of building a blocking table that contains a list of the remaining 
to-do MsgReplys. But then it would be up to me to decide which client is to aquire the lock next, and I think this is 
best left to the Scheduler (e.g. by using a mutex).

Any suggestions?

Greetings,
 Marc