I have a high-priority real-time task that runs every millisecond (the time
quantum of the system). I understand that the round-robin time slice is four
times the time quantum. When my high priority task preempts the low priority
RUNNING task, the RUNNING task will move to the end of the READY queue,
giving the next low priority task a chance to run (as soon as the real-time
task is done). Does this mean that FIFO and RR scheduling regimes will act
identically in my system, given that no task will ever run for an entire
time slice uninterrupted?
Thanks,
Shaun
“Shaun Jackman” <sjackman@nospam.vortek.com> wrote in message
news:ak0lgi$5if$1@inn.qnx.com…
I have a high-priority real-time task that runs every millisecond (the
time
quantum of the system). I understand that the round-robin time slice is
four
times the time quantum. When my high priority task preempts the low
priority
RUNNING task, the RUNNING task will move to the end of the READY queue,
giving the next low priority task a chance to run (as soon as the
real-time
task is done).
No, if your high priority task goes READY, the lower priority RUNNING task
will pre-empt, but does not go to the end of the READY queue. The task will
only go to the end of the READY queue if it consumes its timeslice (in RR).
Does this mean that FIFO and RR scheduling regimes will act
identically in my system, given that no task will ever run for an entire
time slice uninterrupted?
I’m not exactly sure what you’re asking here - In FIFO, only if the thread
blocked/yeilds will it go to the end of the ready queue, allowing other
processes in that priority band to run (or at least be the next READY
thread).
\
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
No, if your high priority task goes READY, the lower priority RUNNING task
will pre-empt, but does not go to the end of the READY queue. The task
will
only go to the end of the READY queue if it consumes its timeslice (in
RR).
I’ve used systems before where any preemption of the RUNNING task (whether
time-slice or priority pre-emption) would send the RUNNING task to the end
of the READY queue. If I understand though, in QNX though, a
priority-preemption leaves the thread at the head of the READY queue for its
priority band. The thread only moves to the end of the ready queue when its
time slice expires, or it BLOCKs and moves to the end of the READY queue
when it unblocks.
I’m not exactly sure what you’re asking here - In FIFO, only if the thread
blocked/yeilds will it go to the end of the ready queue, allowing other
processes in that priority band to run (or at least be the next READY
thread).
My question was based on the assumption that a priority preemption would
also move it to the end of the READY queue for its priority band. If that’s
not the case then no other thread in its priority band (or lower) will run
until it blocks.
Have I understood correctly?
Thanks,
Shaun
I think I can restate he question. It’s a good one.
If a RR process get 4 clock ticks (4 ms in this scenario),
and if it is preempted before it consumes even a single click tick (say 750
us) by a higher priority process,
and if it stays the first task in the READY queue for it’s priority;
when the higher priority process blocks, does this process still get 4 clock
ticks (since it never used up the first click tick)?
The obvious issue is that a CPU bound process at priority X will never give
up the CPU to other priority X processes, even if it is RR, if it never gets
to consume even 1 clock tick before getting preempted.
“Shaun Jackman” <sjackman@nospam.vortek.com> wrote in message
news:ak0vkv$d07$1@inn.qnx.com…
No, if your high priority task goes READY, the lower priority RUNNING
task
will pre-empt, but does not go to the end of the READY queue. The task
will
only go to the end of the READY queue if it consumes its timeslice (in
RR).
I’ve used systems before where any preemption of the RUNNING task (whether
time-slice or priority pre-emption) would send the RUNNING task to the end
of the READY queue. If I understand though, in QNX though, a
priority-preemption leaves the thread at the head of the READY queue for
its
priority band. The thread only moves to the end of the ready queue when
its
time slice expires, or it BLOCKs and moves to the end of the READY queue
when it unblocks.
I’m not exactly sure what you’re asking here - In FIFO, only if the
thread
blocked/yeilds will it go to the end of the ready queue, allowing other
processes in that priority band to run (or at least be the next READY
thread).
My question was based on the assumption that a priority preemption would
also move it to the end of the READY queue for its priority band. If
that’s
not the case then no other thread in its priority band (or lower) will run
until it blocks.
Have I understood correctly?
Thanks,
Shaun
“Shaun Jackman” <sjackman@nospam.vortek.com> wrote in message
news:ak0vkv$d07$1@inn.qnx.com…
I’ve used systems before where any preemption of the RUNNING task (whether
time-slice or priority pre-emption) would send the RUNNING task to the end
of the READY queue. If I understand though, in QNX though, a
priority-preemption leaves the thread at the head of the READY queue for
its
priority band. The thread only moves to the end of the ready queue when
its
time slice expires, or it BLOCKs and moves to the end of the READY queue
when it unblocks.
Yes (since you can’t be on the ready queue when your blocked 
)
My question was based on the assumption that a priority preemption would
also move it to the end of the READY queue for its priority band. If
that’s
not the case then no other thread in its priority band (or lower) will run
until it blocks.
Or consumes its timeslice.
\
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:ak13kb$fkm$1@inn.qnx.com…
The obvious issue is that a CPU bound process at priority X will never
give
up the CPU to other priority X processes, even if it is RR, if it never
gets
to consume even 1 clock tick before getting preempted.
Sure - I agress it’s tough to make forward progress at priority band X, when
there is a process at a higher priority Y constantly going READY at
intervals smaller than a timeslice.
\
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Sure - I agress it’s tough to make forward progress at priority band X,
when
there is a process at a higher priority Y constantly going READY at
intervals smaller than a timeslice.
agress = agree
Coffee is now cut off, due to the sssshhhhaaakkkeeeesss. 
\
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Well, the alternative is pretty straight forward.
Every time a process get put in the READY state, decrement the remaining
tick count (instead of decrementing it at the end of it’s time slice or tick
slice).
The down side to this is that instead of getting 4 clock ticks the process
is getting 4 fractions of a clock tick. After that, it goes to the end of
the ready queue for that priority and the next guy only gets 4 fractions of
a clock tick.
I do agree that if a high priority process is consuming the majority ( >
50% ) of a clock tick on every clock tick, this really represents a flawed
design. But if the system designed is aware of it and can live with it then
it is his choice.
So you are saying that the tick count is not decrement until AFTER the tick
slice completes, and NOT at the beginning?
“Adam Mallory” <amalloryNOSPAM@NOSPAMqnx.com> wrote in message
news:ak14k4$1u2$1@nntp.qnx.com…
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:ak13kb$fkm$> 1@inn.qnx.com> …
The obvious issue is that a CPU bound process at priority X will never
give
up the CPU to other priority X processes, even if it is RR, if it never
gets
to consume even 1 clock tick before getting preempted.
Sure - I agress it’s tough to make forward progress at priority band X,
when
there is a process at a higher priority Y constantly going READY at
intervals smaller than a timeslice.
\
Cheers,
Adam
QNX Software Systems Ltd.
[ > amallory@qnx.com > ]
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
“Adam Mallory” <amalloryNOSPAM@NOSPAMqnx.com> wrote in message
news:ak14h9$1ll$1@nntp.qnx.com…
“Shaun Jackman” <> sjackman@nospam.vortek.com> > wrote in message
news:ak0vkv$d07$> 1@inn.qnx.com> …
My question was based on the assumption that a priority preemption would
also move it to the end of the READY queue for its priority band. If
that’s
not the case then no other thread in its priority band (or lower) will
run
until it blocks.
Or consumes its timeslice.
You need more coffee.
You just told us that it never will consume it’s timeslice or even a tick
slice.
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:ak1bcd$l0t$1@inn.qnx.com…
Well, the alternative is pretty straight forward.
Every time a process get put in the READY state, decrement the remaining
tick count (instead of decrementing it at the end of it’s time slice or
tick
slice).
A problem with that, is that a high priority process that runs periodicly,
preempting lower processes will stop making those processes make forward
progress, since their tick count keeps getting lower even though they aren’t
getting much chance to run.
If you need to service events periodicly at a high priority without starving
out others of a lower priority, look at the sporatic scheduler.
\
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:ak1bgv$l8l$1@inn.qnx.com…
My question was based on the assumption that a priority preemption
would
also move it to the end of the READY queue for its priority band. If
that’s
not the case then no other thread in its priority band (or lower) will
run
until it blocks.
Or consumes its timeslice.
You need more coffee.
You just told us that it never will consume it’s timeslice or even a tick
slice.
I never said “it never will consume it’s timeslice or even tick”. My
statement “Or consumes its timeslice” is a completion of the previous posts
thought: If a high priority thread keeps preempting a lower priority
thread(RR) in band Y, then no other thread in the band Y will run, until the
process which keeps getting preempted, blocks or consumes its timeslice.
Nothing more.
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>