Messages in this thread | | | Date | Mon, 2 Aug 1999 13:53:48 +0200 (MEST) | Subject | Re: priority inversion | From | Bernd Paysan <> |
| |
> Sorry. But spin_locks with sleep is possible and doesn't it defeat > inheritance?
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/
| |