John.Goodenough@SEI.CMU.EDU (01/23/88)
MFeldman asks: > Suppose a lower-priority task has had control of the CPU and no > timeslicing is in effect; suppose that task doesn't do anything to block > itself; suppose the higher priority task was waiting on a delay which > expires. Now - does [9.8(4)] require that we immediately discover the > "eligibility to run"? I have always understood the answer was "no" - that > the decision is allowed to be deferred until the next "synchronization > point". At _that_ point surely the higher-priority task will be scheduled. AI-00032, which has been fully approved, directly addresses this point: !standard 09.08 (04) 87-03-16 AI-00032/09 !class ramification 85-05-18 !status approved by WG9/AJPO 87-03-10 !references AI-00045, 83-00059, 83-00517, 83-00518 !topic Preemptive scheduling is required !summary 87-02-23 If an implementation supports more than one priority level, or interrupts, then it must also support a preemptive scheduling policy. !question 85-01-31 If a task is executing when a task with a higher priority becomes executable because a delay has expired, must execution of the lower priority task cease immediately so execution of the higher priority task can continue? !response 87-02-23 9.8(4) says: If two tasks with different priorities are both eligible for execution and could sensibly be executed using the same physical processors and the same other processing resources, then it cannot be the case that the task with the lower priority is executing while the task with the higher priority is not. Expiration of a delay means a task is eligible for execution. If an implementation determines that a delay has expired for a high priority task, then that task must be scheduled for execution. If the physical processor and other processing resources needed to execute the higher priority task are currently being used by a task of lower priority, execution of the lower priority task must be suspended. If preemptive scheduling is not feasible in a particular implementation, then the implementation should not provide multiple priority levels (see AI-00045) or support interrupts. (Note: the phrase "could sensibly be executed" refers to situations in which the high priority task can actually make use of the processor and other resources being used by the lower priority task. In some distributed processing situations, a high priority task may not be able to execute on some processors. Preemption is only required for processing resources the high priority task can use.) (AI-00045 says an implementation need not provide any priority levels at all.) At one point, my understanding of Ada was the same as Feldman's, but I have been made to see the error of my ways.
barmar@think.COM (Barry Margolin) (01/23/88)
In article <8801221730.AA23176@cs.sei.cmu.edu> John.Goodenough@SEI.CMU.EDU writes: >Expiration of a delay means a task is eligible for execution. If an >implementation determines that a delay has expired for a high priority task, >then that task must be scheduled for execution. However, I think someone already pointed out that a delay only specifies a minimum amount of time for the task to be suspended. An operative point in your response is "if an implementation determines that a delay has expired". It would presumably be legal for an implementation to only check whether delays have expired when a task makes an explicit entry call. In fact, if the only requirement of a delay is that the task suspend for at least that long, it would probably be valid for an implementation to never detect that it has expired; however, the standard should (if it doesn't already) specify that delays should be checked at entry calls. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar