That's because you are considering the _generic_ case. And almost all realtime
deals with the specific. An example may be something like:
High: Monitor a live system (with high tolerance to delay),
writing statistics to disk (locks superblock now and again)
Med: CPU intensive program that almost never touches disk.
Low: RC5 (or something similar) writes to disk occasionally (and
locks the superblock)
In this case the lock for the superblock is held for an unbounded, but
generally very short time. If the low priority process happens to be
pre-empted at this moment, the disk is locked until it gets time again.
Not a pretty sight... _this_ is what needs to be prevented if there is a
real possibility of starving a process for time...
In the "academic" RT literature (and in the _real_ use that caused ?Wind
River? to add priority inheritance) there are many more cases like this that
have bounded times for locking the semaphore, but, because they are in
pre-emptive MT (unlike the kernel) that time might become unbounded. In
the kernel, the time is unbounded in the cases we care about (where it goes
to sleep), but unbounded isn't a carte blanche to make it depend on user
priorities as well...
The generic case doesn't give enough information to tell the difference.
>When Low releases the buffer, all it needs to do is
>scan the list of all processes waiting for any other resources it may hold
>and then resume the highest priority of any of these or its own priority
>if nobody is waiting (this is what Solaris does).
_please_ We can do better than this. Only semaphores (not spinlocks) need
to have the priority inheritance. This can be done with lists off the
semaphore and tasks... You don't really need to scan anything. It does
make the down/up calls more heavyweight. The scheduler doesn't even notice.
Note that the up/down calls would only have to be heavyweight if they had
priority inheritance enabled (i.e. at up, the process has been promoted, and
at down, semaphore is locked by a lower priority process).
>Of course, we need to apply this
>method, not only to buffers, but to any IPC between a RT task and any other
>task, such as the pipe example above.
ehm. Not. The job of the OS is to assure that it doesn't deadlock processes
that wouldn't otherwise deadlock. If a user has a producer process at high
priority and a consumer at low priority he loses. That's not deadlock, that's
just simple poor assignment of priorities.
Note that I lost track of exactly what the deadlock was, but, for example,
locking a super-block and then sleeping might have exactly this effect...
-gordo
-- ----------------------------------------------------------------------- Gordon Oliver, member of Distributed Idea Group (http://www.digroup.com)
- 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/