From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,5b15c37c5d0c986f
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!newsfeed.arcor.de!news.arcor.de!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Designing Timers using Ada.Real_Time.Timing_Events package
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.14.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <1143317010.868435.251190@v46g2000cwv.googlegroups.com>
 <1d4yew2i587h5.1h8dilwbda4zv.dlg@40tude.net>
 <1143351567.528574.297850@z34g2000cwc.googlegroups.com>
 <1fiau0e4pe84o$.gulfgysczk5i$.dlg@40tude.net>
 <1143389936.844624.243020@i40g2000cwc.googlegroups.com>
 <bft5k6q6t38k.1rjkfpfel3c8p$.dlg@40tude.net>
 <1143402228.182836.29570@v46g2000cwv.googlegroups.com>
Date: Mon, 27 Mar 2006 09:49:59 +0200
Message-ID: <1pvsgg60odxin$.16vcgq2jyhf8g$.dlg@40tude.net>
NNTP-Posting-Date: 27 Mar 2006 09:49:59 MEST
NNTP-Posting-Host: f9f0861a.newsread2.arcor-online.net
X-Trace: 
 DXC=NJAPP<NhbYj<_V8dMIHdjhQ5U85hF6f;djW\KbG]kaMhDAHcn;Zl5ehc0cZF<kE=ee[6LHn;2LCVn7enW;^6ZC`dIXm65S@:3>o
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:3649
Date: 2006-03-27T09:49:59+02:00
List-Id: <comp.lang.ada>

On 26 Mar 2006 11:43:48 -0800, Anh Vo wrote:

>>> 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.

The implementation goes roughly as follows (a modified Barnes code from
"95th rationale".) Presuming multiple waiting tasks and Signal required to
be a procedure, rather than an entry:

-- Main entrance (is closed during notification) The reason is
-- to aviod irace condition upon timer event. Otherwise a task
-- might get it twice.
entry Wait_For when Inactive or not Occured is
   if Inactive then
      raise Timer_Canceled;
   else
      requeue Wait_Notify with abort;
   end if;
end Wait_For;

-- The notification queue, this is a private entry point to gather
-- the waiting requests.
entry Wait_Notify when Inactive or Occured is
   if Inactive then
      raise Timer_Canceled;
   end if;
end Wait_Notify;

procedure Set (Period : Time_Span) is
begin
   -- attach Signal to the timer
   Inactive := False;
end Set;

procedure Signal (...) is
   Occurred := True;
end Signal;

procedure Stop is
   -- detach Signal from the timer
   Inactive := True;
end Stop;

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

The "main program" is just a task (thread.) If it participates in deadlock,
it hangs, if it does not, then it doesn't. (:-))

The problem with synchronous messages (~callbacks) is that ithey are quite
easy falli into a deadlock. The example is Windows API. Typical scenario is
you take a mutex, send a message and spin for that mutex in the message's
callback. Thing like this happen on daily basis.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de