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!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe03.iad.POSTED!7564ea0f!not-for-mail 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: <4ABCF87D.2090103@shaw.ca> <1m2k0pew7wla9$.1bml843g8z0in$.dlg@40tude.net> In-Reply-To: <1m2k0pew7wla9$.1bml843g8z0in$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <709vm.1523$3G7.161@newsfe03.iad> NNTP-Posting-Host: 70.72.159.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe03.iad 1253907587 70.72.159.148 (Fri, 25 Sep 2009 19:39:47 UTC) NNTP-Posting-Date: Fri, 25 Sep 2009 19:39:47 UTC Date: Fri, 25 Sep 2009 13:39:48 -0600 Xref: g2news2.google.com comp.lang.ada:8473 Date: 2009-09-25T13:39:48-06:00 List-Id: Dmitry A. Kazakov wrote: > This would mean that the hardware device encapsulated that task (e.g. HDD > controller). I don't think this could be considered a realistic scenario. > Hardware I/O on most platforms is too slow to be performed from a protected > action. If you have an OS, it is 10-100 times slower, at least. Doing this > within a protected action is not a good idea. One can imagine protected > action as a being performed by a task with highest real-time priority. > Without OS, considering low-level I/O, like DAQ boards, DMA access etc, the > performance penalty might be even higher. I was thinking more along the lines of changing the voltage of some output port on some device, or writing directly to the console buffer, rather than invoking some dialog with a HDD controller. Depending on the device, it may be as simple as writing a single value to some memory address. Technically, this is a non-blocking scenario. It may (or may not) be slower than normal memory writes, but still satisfies RM 9.5.1(8). Just because it is protected, does not mean it cannot be preempted by a higher priority (e.g. interrupt) task. It wont cause deadlock. I think this is very much a realistic scenario. > >> 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. > > No, because these events need to be handled by somewhere. Million events > handled by one task? That is the monitor task taking the shortest delay > from a queue of. Million tasks will not work anyway. I was agreeing with you that scalability could become an issue. Channeling everything through a single timer task (if that is how it is implemented) could introduce unacceptable latencies, if the number events grows too large. >>> 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. > > This is IMO a different case, e.g. pulse events. Yes I have an > implementation of pulse events. But I don't see why pulse events cannot be > signaled from a scheduler task. The event source is unrelated to the way an > event is handled. Basically Timing_Events saves you exactly one "scheduler" > task, keeping in mind that the implementation of could deploy some hidden > task (thread) anyway. It does not save you the worker task(s). > Agreed, timing_events *is* basically a scheduler task. In my example, assuming Call_Police is not potentially blocking, and you try to rewrite the example without having some type of a scheduler task, (whether it be timing_events or your scheduler), then you may end up having to create some dedicated task to manage the timeout for the alarm. (Extra to the thread of control encapsulated by the hardware device) The scheduler model could be considered as being an improvement over this, but as system requirements can differ dramatically across different systems, YMMV. Regards, Brad