On Tue, Feb 09, 1999 at 12:08:53PM +0100, Peter Steiner wrote:
> Of course, one deadlock might be:
>=20
> - a low priority process gets (owns?) a lock=20
> - 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 (=3Dlower 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,
--=20
Kurt Garloff <kurt@garloff.de> [Dortmund, FRG]
Plasma physics, high perf. computing [Linux-ix86,-axp, DUX]
PGP key: see mailheader [Linux SCSI driver: DC390]
--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
iQCVAwUBNsFYGhaQN/7O/JIVAQFH6gP9FBwnKxsd+EeGtN5ZqBDoAcKc7aLJ+n9O
RAzGMBN77W5Ejh2DJMORQyxYPqppG25NPvAh3hFqpcIsjZf0MnAFV9D1RbVA+C4a
zprJOmbD+4Ez+ThWgjSXChL+Do9bmRrpNUtxGhp2EXoDAiaiRlRjbeBO4TOAg1Jc
DarHm/riAkI=
=hocL
-----END PGP SIGNATURE-----
--vkogqOf2sHV7VnPd--
-
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/