MFELDMAN@GWUVM.BITNET (Mike Feldman) (01/25/88)
Now I'm really baffled. John quotes a recent interpretation to the effect that an implementation supporting multiple priorities must support preemption. Maybe my naivete about operating systems is showing, but that seems to be to require that an implementation with multiple priorities _must_ be done on a platform providing timer interrupts. Otherwise, how would expiration of a delay be detected (not by continuous polling, I hope!)? I've always thought that it was quite reasonable to allow one of a number of cooperating tasks to run until it blocked, _then_ have the scheduler see who's eligible and schedule the one with the highest priority. It seems to me that - given the "weak" nature of priorities in Ada anyway - priorities and preemption can be treated independently. Seems a bit too stringent to tie them together: priorities are only "advisory" in nature, and static, in any case. Oh, well. So let me get this straight: does a system supporting multiple priorities have to detect _immediately_ (and what does _that_ mean?) the expiration of a delay so that it can pre-empt the running task if the one that just "woke up" has a higher priority? Is this policy now being implemented in an ACVC? I have seen one recently pre-validated implementation which indeed seems to follow the policy (Janus/Ada), in the sense that it has a "run till blocked" scheduling policy and only a single priority level. It looked to me like they were just trying to simplify their scheduler. But now I get the impression that the single priority scheme is a consequence of this recent ruling. Meridian, on the other hand, has a "run till blocked" scheduler but multiple priorities - so do many others, I think. Clearly ACVC 1.8 permitted it (Meridian validated under it). Does 1.9 forbid it? I can see a _lot_ of work coming for implementers validating under post-1.8 ACVC's. Or am I missing something important?