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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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!postnews.google.com!v46g2000cwv.googlegroups.com!not-for-mail From: "Anh Vo" Newsgroups: comp.lang.ada Subject: Re: Designing Timers using Ada.Real_Time.Timing_Events package Date: 26 Mar 2006 11:43:48 -0800 Organization: http://groups.google.com Message-ID: <1143402228.182836.29570@v46g2000cwv.googlegroups.com> 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> NNTP-Posting-Host: 71.146.81.142 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1143402236 26450 127.0.0.1 (26 Mar 2006 19:43:56 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 26 Mar 2006 19:43:56 +0000 (UTC) In-Reply-To: User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: v46g2000cwv.googlegroups.com; posting-host=71.146.81.142; posting-account=JVr7Xg0AAAAI3MbuARxMmvWLmA7qdJMx Xref: g2news1.google.com comp.lang.ada:3639 Date: 2006-03-26T11:43:48-08:00 List-Id: >> 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