Messages in this thread | | | Date | Wed, 10 Feb 1999 10:57:46 +0100 | From | Kurt Garloff <> | Subject | Re: Real Time scheduler? |
| |
On Tue, Feb 09, 1999 at 12:08:53PM +0100, Peter Steiner wrote: > Of course, one deadlock might be: > > - a low priority process gets (owns?) a lock > - a normal process gets into an endless loop before the low priority > process returns the lock. This totally locks the low priority > process.
This was discussed in this list, previously ...
Problems like this one are known as PRIORITY INVERSION: The process with higher priority (=lower nice values) waits for a resource (or data) hold by a low priority process. Now, effectively, the high priority process is running at the priority of the low prio process. If the low prio process may never get scheduled (SCHED_IDLE), this is particularily bad, as the process could be stalled. I think that's the reason, why the SCHED_IDLE patch (which I like very much!) didn't go into the kernel.
The solution is PRIORITY INVERSION: If a high prio process is waiting for something a low prio porcess provides, the low prio process should temporarily get the high prio. If the processes are passing data through the kernel or using kernel's resources, it should be detected by the kernel. If data is passed in memory (shared mem, e.g.), it's up to the userspace implementation to take care.
Regards, -- Kurt Garloff <kurt@garloff.de> [Dortmund, FRG] Plasma physics, high perf. computing [Linux-ix86,-axp, DUX] PGP key: see mailheader [Linux SCSI driver: DC390] [unhandled content-type:application/pgp-signature] | |