Re: Re:without message queue

Hi Slava

One important adjustment has to be made (if you don't > mind, I will make
an "ad-hoc assumption" that we are >speaking about UP machine). Your
statement becomes true
only when the target thread starts running - at this >point no one, apart
from itself, can make it yield the
CPU, so that all other threads have to wait. However, in > order to become
immune to context switches, the target
thread needs to start running, in the first place.

This is incorrect. If a priority of a thread is such that it cannot be
pre-empted by any other thread, then it will pre-empt any other thread as
soon as it becomes runnable.


I am afraid you misunderstood me. Look at my statement:
" It is understandable that, at some certain point, your thread has to yield
the CPU, so that some other thread gets a chance to run". I did not say that
your thread would get pre-empted by some other thread, did I???? Instead, I
meant that it would yield the CPU voluntarily. Consider the following

Your real-time priority thread voluntarily yields the CPU by entering
waiting state by, say, suspending itself for 50 ms - as long as it is in
waiting state, it is not eligible for execution, regardless of its priority.
Meanwhile, some other real-time priority thread starts running, and does not
yield the CPU for, say, 5 seconds.

It is understandable that, in such case, your thread will be unable to run
for 5 seconds, regardless of its real-time priority. In other words, as long
as your thread runs, no one, apart from itself, can make it yield the CPU.
However, if it yields the CPU .... at this point it loses its immunity to
freezes, regardless of its real-time priority

But I do not think we were talking about a system that would host more than
one real-time application.

If it was someone else who made the above statement, you would definitely
say that this is "ad-hoc assumption"

My statement, however, was even more modest. I meant that disk activity
would not interfere with a high priority thread.

I would say that, under the normal circumstances, disk activity should not
be a problem. However, if the OP wants to be 100% sure that the delay will
NEVER EVER exceed 1 second, no matter what happens...... in such case I
would say that Windows NT is not the platform that provides any guarantees,
as far as scheduling is concerned. At the same time, I don't think any
application that does not mind 1-sec delays can qualify for being
time-critical one, so that eventual delays in excess of 1 second should not
pose too serious problems for such applications

Anton Bassov

Relevant Pages

  • Re: Dont really understand Thread.yield()
    ... > if a thead calls yield()? ... moved to the end of its priority ... so the new currently running thread is selected among ... If there are other threads with the same priority as the yielding ...
  • Re: wait vs. yield?
    ... how that platform schedules threads. ... way to use yield() and get the same effect on multiple platforms. ... hope that all threads with priority equal to T1's will get a chance ... Pthreads has yieldanalogs. ...
  • Re: Resent: BUG in RT 45-01 when RT program dumps core
    ... This is a check that we have to flag when a RT task calls yield. ... So if the RT task is yielding to let a lower priority task ... send the line "unsubscribe linux-kernel" in ...
  • Re: iperf yield usage
    ... there's plenty of recourse possible to all possible kinds of apps. ... yielding task to the end of that priority level) while now they're ... not really - the old yield implementation in essence gave the task a ... the old one requeued yield-ing tasks to the 'active array', ...
  • Re: sched_yield: delete sysctl_sched_compat_yield
    ... having it give up _some_ priority (like the old scheduler) is less ... having a _more_ agressive yield than 2.6.22 ... Actual Java app server benchmarks ... for the given priority level as you know (ie. at the end of all other ...