That's indeed a problem. I would say that holding a lock for longer than
absolutely necessary should be avoided anyway. Holding a lock should ensure
atomic operations (wrt the respective context).
You can have locks that sleep for an I/O completion, though. Then, the
interrupt should also release the lock(s).
> So:
> P0: get sem A, inherit priority X; sleep on I/O; lose priority X
> while holding A
> ?is this correct?
Yes, that can happen. One thing you can do about this is *not* puting the
higher priority process (P1) waiting for the lock to sleep, but just queue
it after the process that has the lock. Thus, once that process goes to sleep
(losing the priority), P1 awakes, looks if it got the semaphore, and
promotes P0 again when not.
> Ok. Now we have a basis for discussion. What's the gain that makes
> "somewhat costly" addition to common case worth it?
The current spin locks have no information of who owns the lock; thus
atomic sets would have to be replaced by something like compare and swap (if 0,
put current there). Is it worth to do that for spin locks? Well, for some,
certainly no (spin locks with cli can't be preempted, anyway). I think it's
only worth to do that for locks you want to hold for quite a time, and where
preemption while holding the lock can be good. Then, for those locks, the
costs are neglectible, anyway (you do so much work in between). Locks you want
to hold short for atomic operations should just make the process
non-preemtible for the time of holding the lock.
-- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/Sent through Global Message Exchange - http://www.gmx.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/