Re: Advice, tasking and hardware

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

On 05/26/2016 09:41 AM, patrick@spellingbeewinnars.org wrote:
> 
> I could write a mostly single threaded application that used tasking for
> error detection/handling only.
> 
> I could queue tasks. One would be called just before calling into a driver.
> The task would delay for a given amount of time and if the call to the driver
> blocked unexpectedly the task would reach a point were it will notify the
> user with a detailed error message. If the driver call did not block another
> task would be called to signal that the driver call completed on time and the
> first task would be notified at rendezvous that it was on time and the tasks
> would queue again and wait for the next driver call.

It sounds like you're interested in a "watchdog", which does something if an
action doesn't complete in time. Possible ways to implement this include the
selective abort (ATC), a timing event, or using a task.

ATC is simple:

select
   delay until Deadline;

   -- Whatever reporting or corrective action is needed
then abort
   Perform_Action;
   -- Whatever success reporting is needed
end select;

If the delay expires, an attempt is made to abort the "then abort" part.
Obviously you wouldn't use it if you don't want to abort the call. Note also
that there are things that cannot be aborted, so this may not work if
Perform_Action contains any of them. You should review ARM 9.8 to see if they
apply to you.

http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-9-8.html

A timing event (ARM D.15) has an associated handler, which is a protected
procedure. Depending on what your compiler will let you get away with in a
protected operation, and how concerned you are about portability, you may be
able to put your reporting/recovery in the handler, and this is almost as simple
as ATC, though it's a bit harder to find out what the recovery options are. If
you want to do any potentially blocking operations, to be portable, your handler
needs to simply open the barrier on an entry of the same PO, and a task that
waits on that entry does the actual recovery. If you're going to do that, it's
simpler and clearer to just use a task.

You'd use a timing event this way

Event.Set_Handler (At_Time => Deadline, Handler => PO.Handler'access);
Perform_Action;
Event.Cancel_Handler (Cancelled => Canceled);

Deadline needs to have enough slack in it to prevent a race condition between
the handler being invoked and Cancel_Handler being called.

A task would look like

task Watchdog is
   entry Start (Deadline : in Time);
   entry Stop;
end Watchdog;

and is used similarly to a timing event

Watchdog.Start (Deadline => Deadline);
Perform_Action;
Watchdog.Stop;

and has a similar comment about race conditions.

The body of Watchdog is like

Forever : loop
   select
      accept Start (Deadline : in Time) do
         Expiry := Deadline;
      end Start;
   or
      terminate;
   end select;

   select
      accept Stop;
   or
      delay until Expiry;

      -- Recovery
   end select;
end loop Forever;

Note that this could be generic on the recovery action.

-- 
Jeff Carter
"This trial is a travesty. It's a travesty of a mockery of a
sham of a mockery of a travesty of two mockeries of a sham. ...
Do you realize there's not a single homosexual on that jury?"
Bananas
27