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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,a4db0fc323f0b09e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe19.iad.POSTED!7564ea0f!not-for-mail Message-ID: <4ABCF87D.2090103@shaw.ca> From: Brad Moore User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Barrier re-evaluation issue with GNAT 4.3.2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 70.72.159.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe19.iad 1253898365 70.72.159.148 (Fri, 25 Sep 2009 17:06:05 UTC) NNTP-Posting-Date: Fri, 25 Sep 2009 17:06:05 UTC Date: Fri, 25 Sep 2009 11:06:05 -0600 Xref: g2news2.google.com comp.lang.ada:8470 Date: 2009-09-25T11:06:05-06:00 List-Id: Dmitry A. Kazakov wrote: > 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. A real implementation of Call_Police would hopefully have more effect then just printing a message to a console. Yes, Text_IO.Put_Line is potentially blocking and clouds the example, thanks for catching that. Conceivably though, it may be possible to use some other console output that is non-blocking if Call_Police really does need to log something to a console. Also, Call_Police does not necessarily need to involve a task. For example, it may simply raise a signal on some hardware device that calls 911, or turns on a siren, or flashing lights or whatever. Even if it does perform some protected operation that kicks off another task, the timing event approach might hold appeal to some, or be more of an appropriate design choice, though in that case, I would probably recommend at least considering some other approach such as the use a timed/conditional entry call. Timing_Events should handle a reasonable number of events in the system. If your application has millions of these firing all over the place, then scalability could become an issue, and perhaps for such a system, some alternate design would be more appropriate. > > ----------- > 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. > I see timing events as being potentially useful reusable concurrency component. If you ever need something that looks like timing_events, then hopefully it will save you from having to write your own. It may have utility in some areas such as discrete event simulation, for example, if you need something to coordinate multiple tasks and ensure that signalling events occur and run to completion before before signaling subsequent events. Whether timing_events is something that will be used a lot in practice is another question. I worked on a legacy system (written in Ada 83) that had a package very similar to timing_events. It was used to trigger timeouts in a run-to-completion tasking model. In that environment, the creation of tasks was discouraged, and only allowed if absolutely necessary. This timing_events package provided a convenient way to coordinate the existing tasks and trigger things to happen in the future without having to introduce more tasks in the system. Of course, as with the standard timing_package, timing events need to be non-blocking and fast. Had the standard timing package existed at that time, we probably would have used that instead. If I were building the system again from scratch, though, maybe I wouldn't use timing_events at all. I suspect that some people will find timing_events to be useful for specific types of applications, but probably will not be used on any grand scale. I think mostly people should/will want to use other existing synchronization mechanisms in Ada to coordinate tasks. Brad