Re: Elegant 'abort' of sleeping task

[Jeffrey Carter <spam@spam.com>]

Simon Apperley wrote:
> 
> I'm looking at the design of a piece of server code which has to
> handle calls that also pass a timeout value. The target system is
> aerospace related, and dynamically creating tasks 'on the fly' just is
> not an option.
> 
> I want to be able to set up a single task to handle the timeout from
> the head of a delta-queue of timeouts, but have found a problem. If I
> have the timeout implemented as a task stuck in a 'delay' call, and a
> more immediate timeout comes in, I want to wake up the sleeping task,
> re-calculate the delta-queue and then sleep on the new, shorter,
> delay. So far the only way I can see to do this is to use abort, and
> set up the task again, which seems a bit of a brute force approach.

It sounds as if you have something like

loop
    -- get Timeout
    delay Timeout;
    -- post timeout processing
end loop;

in which case you might be able to do something like

loop
    -- get Timeout
    loop
       select
          accept New_Timeout;
          -- get Timeout;
       or
          delay Timeout;
          -- post timeout processing

          exit;
       end select;
    end loop;
end loop;

This is a timed select, but it has the effect you desire. If nothing 
happens during the timeout period, the task is delayed for that period 
and then the post timeout processing occurs. Then it gets the next 
timeout period. If a new timeout value becomes available during a 
timeout, you make a call to the New_Timeout entry, which immediately 
results in the task obtaining a new value for Timeout and performing the 
timed select again with the new value.

> I did wonder about delay until TIME, and having another task change
> TIME, but that seems rather un-safe to me as it starts making
> assumptions about the underlying run-time implementation.

All delays are defined in terms of delay until, so you can certainly use 
delay until in this construct, and it will probably simplify your code. 
But what you're talking about won't work. Changing the variable after 
the delay until has commenced doesn't change the time at which the delay 
expires. One way to consider this is that the delay until effectively 
stores the current value of your variable. Ada does a lot of this kind 
of thing; for example

    I : Integer := 5;
begin
    for J in 1 .. I loop
       I := 10;

loops 5 times. Changing the value of I doesn't change the loop bounds.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life