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-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.71.MISMATCH!xlned.com!feeder3.xlned.com!news2.euro.net!newsfeed.freenet.de!bolzen.all.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Barrier re-evaluation issue with GNAT 4.3.2 Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.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: Date: Fri, 25 Sep 2009 11:17:32 +0200 Message-ID: NNTP-Posting-Date: 25 Sep 2009 11:17:32 CEST NNTP-Posting-Host: c40868a6.newsspool4.arcor-online.net X-Trace: DXC=8OkCYR\VB\=RadXUBHgFh34IUKkg2nk5Ai:cHFD7 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8462 Date: 2009-09-25T11:17:32+02:00 List-Id: On Fri, 25 Sep 2009 02:50:32 -0600, Brad Moore wrote: > Dmitry A. Kazakov wrote: >> I was always wondering the rationale behind introducing >> Ada.Real_Time.Timing_Events. The delay statement does the very same thing: >> >> with Ada.Real_Time; use Ada.Real_Time; >> ... >> Event : Time; >> begin >> ... >> Put_Line ("Starting alarm ..."); >> Event := Clock + To_Time_Span (3.0); >> >> Put_Line ("Waiting for alarm ..."); >> delay until Event; >> Put_Line ("ALARM!!"); > > In this trivial example, a simple delay is probably all you need. > > However, consider a slightly different twist on the alarm example. > Suppose you have a burglar alarm where if you trip the alarm > you have 1 minute to correctly enter the security code, or > the police are called. If you correctly enter the code in time > the alarm is canceled. This gets you into the realm where > the timing events package is more useful. > > You could accomplish this also using a task to monitor the timeout, but > that could be considered a "heavier" approach depending on the > implementation of the timing events package. Timing events provide a > simpler abstraction, if all you want is an event to fire at sometime in > the future. Plus if you have many such sort of events in a program, you > could potentially save yourself from having to add tasks for each event > you want to monitor, resulting in less system resources being used. You must do it per a monitor task anyway. Your design is not scalable, and the code is not conformant to Ada, because you are using potentially blocking Put_Line within a protected action (in Call_Police). When an alarm is triggered, that happens at the context of a protected action. The protected action is quite limited to what you could do there. That is only non-blocking and *very* short stuff. This means that you won't be able to "call police" from there. You could set some flags, but you could not initiate any "non-instant" action otherwise than by releasing a task. Non-instant actions are for tasks. You need a task. If the key input task gets blocked beyond reach of asynchronous transfer of control, which is your case, because Ada does not require Text_IO abortable (yet misleadingly provides an example of in RM (:-)), anyway, that means, you inescapably need a second task. ----------- Timing_Events does not have any advantages over delay or asynchronous transfer of control. I guess it was provided for some low-level stuff like interrupts from hardware timers. However there was already a support for interrupts mapped into protected operations, so it really puzzles me why Timing_Events were added. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de