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!news2.google.com!news4.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!oleane.net!oleane!news.in2p3.fr!in2p3.fr!kanaga.switch.ch!switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" 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> Date: Sun, 26 Mar 2006 20:22:03 +0200 Message-ID: NNTP-Posting-Date: 26 Mar 2006 20:21:55 MEST NNTP-Posting-Host: c734aa7a.newsread2.arcor-online.net X-Trace: DXC=cYSYUU:>c=fCUhGd:LVK2eQ5U85hF6f;djW\KbG]kaMhDAHcn;Zl5eh;DQc\P1U9?n[6LHn;2LCVn[ On 26 Mar 2006 08:18:56 -0800, Anh Vo wrote: >>> I did not know that it is possible to use protected objects >>> functionally while each timer used for different purpose. Could you >>> elaborate further? > >> Why not? Each protected object would be a simple event. The handler set for >> Ada.Real_Time.Timing_Events triggers an event(s). The functionality, i.e. >> what has to be done upon the event, is outside. It happens in the task >> waiting for the event. > > 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 don't know the details of Ada.Real_Time.Timing_Events, but it should be possible to do something like above.) >> Decoupling. The model one task - one callback is too specialized and >> exposed to misuse. You might wish to have more than one task, you might >> want handling the timer events on different contexts, routing and >> re-routing them between tasks. > > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de