Task reschedule

Task reschedule

[Gruntfuggly]

I've always believed that 'delay 0.0' should cause a task reschedule. 
However, it appears that my compiler simply optimizes the statement out.

Is there another way I can force the reschedule? I don't want to have to 
put it a '0.02', but if I put in a line of Text_IO instead, that gives 
me the correct functionality...

Nige

Re: Task reschedule

[David C. Hoos, Sr.]

How about delay Duration'Small; ?

----- Original Message ----- 
From: "Gruntfuggly" <nigel.scott@uk.thalesgroup.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: August 05, 2002 7:46 AM
Subject: Task reschedule


> I've always believed that 'delay 0.0' should cause a task reschedule. 
> However, it appears that my compiler simply optimizes the statement out.
> 
> Is there another way I can force the reschedule? I don't want to have to 
> put it a '0.02', but if I put in a line of Text_IO instead, that gives 
> me the correct functionality...
> 
> Nige
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: Task reschedule

[Stephen Leake]

Gruntfuggly <nigel.scott@uk.thalesgroup.com> writes:

> I've always believed that 'delay 0.0' should cause a task reschedule.
> However, it appears that my compiler simply optimizes the statement
> out.
> 
> Is there another way I can force the reschedule? I don't want to have
> to put it a '0.02', but if I put in a line of Text_IO instead, that
> gives me the correct functionality...

If you give each task a distinct priority, the highest priority one
will run when it is ready.

Or you can enable time-slicing, if you don't actually care where the
task switch happens.

If you are using a round-robin scheme, you'll have to use an OS call
to put the current task to sleep.

It seems odd to not use time-slicing for this. If you actually care
where the task switch happens, you should use a rendezvous or
protected object to force the task synchronization.

-- 
-- Stephe

Re: Task reschedule

[tmoran]

> > I've always believed that 'delay 0.0' should cause a task reschedule.
> > However, it appears that my compiler simply optimizes the statement out.

> How about delay Duration'Small; ?

  "The implementation shall document the minimum value of the delay
expression of a delay_relative_statement that causes the task to actually
be blocked."  ALRM (optional) D.9(7)  Of course blockage means till the
next clock tick, which may be an amazing long time with some systems.

D.9(14) "The execution time of a delay_statement that does not cause the
task to be blocked (e.g. 'delay 0.0;') is of interest in situations where
delays are used to achieve voluntary round-robin dispatching among
equal-priority tasks."  That certainly ought to cause embarrassment,
at the least, to the vendor of a compiler that ignores a "delay 0.0;".

Re: Task reschedule

[Randy Brukardt]

Gruntfuggly wrote in message ...
>tmoran@acm.org wrote:
>>   The "delay 0.0;" may mean "This task is in a cyclic or polling loop
>> that doesn't need short latency, so I'd like to give other tasks in
the
>> system a chance to run".  Given that you don't know what other tasks
may
>> exist, how can you code that with a rendezvous?
>>   IIRC, a couple of years ago I measured Apex/W2k and found that
>> "delay 0.0;" took 10 ms (1 clock tick).  I'd be curious about your
>> results compiling and running the timetest program at
>> www.adapower.com/reuse/tt.html


>If I read that correctly, it does look like the delay 0.0 is ignored...


Yes, you read that correctly. What Tom didn't tell you is that the
reason that he wrote Timetest was because of a Claw customer whose
program ran unreasonably slow. We traced the problem to the delays in
the Claw server task (which unfortunately has to poll Windows for
messages).

The "solution" to the problem in Claw was a Rational-specific patch: use
a Windows "Sleep(0)" API call instead of delay 0.0;. This provided
correct performance. Perhaps a similar solution would work on Solaris??

(The Claw server task uses a "ladder" of delays to provide quick
response when messages are coming in rapidly, yet avoid hogging the CPU
when nothing is happening. It's possible to write a program which gets
lousy GUI performance by causing operations to occur at just under the
frequency of the first real delay, but that rarely happens in practice.
Note that a GUI is certainly not a real-time application, but you don't
want any single task to hog all of the CPU - especially as that might
hog the GUI locks as well.)

                      Randy.