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
scenario:


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
.