* Preemption and priorities
@ 1988-01-22 17:30 John.Goodenough
1988-01-23 0:23 ` Barry Margolin
0 siblings, 1 reply; 2+ messages in thread
From: John.Goodenough @ 1988-01-22 17:30 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Preemption and priorities
1988-01-22 17:30 Preemption and priorities John.Goodenough
@ 1988-01-23 0:23 ` Barry Margolin
0 siblings, 0 replies; 2+ messages in thread
From: Barry Margolin @ 1988-01-23 0:23 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1988-01-23 0:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1988-01-22 17:30 Preemption and priorities John.Goodenough
1988-01-23 0:23 ` Barry Margolin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox