Re: Designing Timers using Ada.Real_Time.Timing_Events package

["Anh Vo" <anhvofrcaus@gmail.com>]

>> it works only if there is a specific purpose associated with an event.
>> In other word, an event handler must be set for a specific action. The
>> timers work almost like a generic in that the event is set once. The
>> action is supplied at the time of instantiation.

> Where is any problem? Event is decoupled from any purpose its signalling
> might have. You do:

> Timer_Canceled : exception;

> protected type Periodic_Timer is
>   entry Wait_For;
>      -- May raise Timer_Canceled
>   procedure Set (Period : Time_Span);
>      -- Sets. reset timer
>   procedure Cancel;
>      -- Stops timer. Any task in Wait_For queue gets Timer_Canceled raised
>   entry Simulate;
>      -- Simulates a timer event
> private
>   procedure Signal (...);
>      -- To be set as a handler for Ada.Real_Time.Timing_Events
>   [...]
>      -- Some internal entry to requeue Wait_For, if Signal cannot
>      -- be an entry, but must be a protected procedure, instead.
>   Inactive : Boolean := True;
> end Periodic_Timer;
>
> No tasks needed. Any number of tasks may wait for timer events. What they
> do upon an event is up to them, as well as to take care if they catch all
> events. So there is no deadlock if one of them hangs somewhere.

I need to digest your design more details at implementation level to if
it works a intended. I recall that during testing if a deadlock occurs
in one event, the main program hung. That means the other callback did
not run due to the main program hung or the deadlock happening from the
earlier callback. I will post the resullts after implementing and
testing your design.

Regarding deadlock in general, if a deadlock occurs in one task, should
other tasks continue to operate and the main program should not hang?

>> For each timer defined through derivation, it is run under a separate
>> task. In case of Safe_Timers there are two tasks, additional task
>> needed for decoupling, running. Therefore, they are completely
>> separated between callbacks.

> So, when they, for example, must be the same task you will have a problem.
> This design is too fragile.

If deadlock occurs in one callbacks causing problems in others as
mentioned abouve, it is a fragile design indeed.

AV