> IIRC the Windows locks which interact with the scheduler have a similar feature
where the owning thread ?inherits? the priority of the highest waiting thread.
In fact, I was totally unaware of the priority inheritance support under Windows NT up to this point, but I have to admit that my knowledge of Windows NT may be rather outdated. In which OS version did they introduce it?
This all works great as long as the lock will be held for a long time ? and if it is not held
for a long time, entirely irrelevant.
For modern systems, any design that holds locks for a long time is a bad
one and so all of this priority inheritance stuff is mostly irrelevant.
Well, strictly speaking, you don’t have to hold a lock for too long in order to be in a position to cause the priority inversion scenario - the only thing that you need is to get preempted while holding the lock. OTOH, the longer you hold locks, the more likely the above "unfortunate scenario’ to occur.
Concerning the (ir)relevance part, the whole thing is, indeed, mostly irrelevant in the world of GPOSes. It mainly applies in the world of hard RTOSes where “missed_deadline==failure” statement alway holds true. Therefore, such an OS has to be 100% predictable, because you have to be always in a position to evaluate the worst possible case/scenario, i.e. the longest delay that is theoretically possible.
The most likely scenario when you may need something like that under GPOS is deferred interrupt processing in context of a thread, rather than in an atomic one. Some GPOSes like Solaris and FreeBSD (and, to some extent,Linux) allow you to defer interrupt processing to so-called “interrupt thread”, effectively giving you an option of using dispatcher-level synch constructs in your DPCs.
Unless you are using a dedicated thread for every deferred processing item (which may be simply an overkill), putting such a thread out of play for too long may have very negative overall consequences for the system. This is why both Solaris and FreeBSD support the turnstiles
that allow you to deal with the priority inversion problem to some extent (although don’t provide a 100%-reliable solution to it for the reasons that I have explained in my previous post)
When it comes to Windows NT, there is no such thing as “interrupt thread” in the Windows world.
The only thing that Windows offers is a ridiculous concept of a “threaded DPC”,
i.e. the one that may , but is not guaranteed to, run at IRQL<dispatch_level.>Once you are not guaranteed that your routine is going to run at IRQL<dispatch_level you cannot use dispatcher-level synch constructs in it which simply defeats the purpose of whole exercise>
OK, it is time for me to shut up - the new list management platform with “scary” troll-management features is on the way, and must be already somewhere pretty close. After all, the term “trolling” seems to have a wide range of interpretations in this NG, and may include something as innocuous as questioning the practical usefulness of “typedef int INT”-like declarations. Therefore, it is better for me not to provoke “The Hanging Judge’s” wrath by criticising “the genius” of Windows NT design.
Anton Bassov</dispatch_level></dispatch_level.>