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: 103376,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!o13g2000cwo.googlegroups.com!not-for-mail From: "jimmaureenrogers@worldnet.att.net" Newsgroups: comp.lang.ada,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 9 Mar 2005 11:27:57 -0800 Organization: http://groups.google.com Message-ID: <1110396477.596174.285520@o13g2000cwo.googlegroups.com> References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <112sonip5v4dca6@corp.supernews.com> <112t3de6fu04f38@corp.supernews.com> NNTP-Posting-Host: 209.194.156.4 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1110396483 12032 127.0.0.1 (9 Mar 2005 19:28:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 9 Mar 2005 19:28:03 +0000 (UTC) In-Reply-To: <112t3de6fu04f38@corp.supernews.com> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: o13g2000cwo.googlegroups.com; posting-host=209.194.156.4; posting-account=SqOfxAwAAAAkL81YAPGH1JdBwpUXw9ZG Xref: g2news1.google.com comp.lang.ada:8971 comp.realtime:1152 comp.software-eng:4710 Date: 2005-03-09T11:27:57-08:00 List-Id: CTips wrote: > Jim Rogers wrote: > > > CTips wrote in > > news:112sonip5v4dca6@corp.supernews.com: > > If you want different scheduling policies you write them, just as > > in C or C++. > > Right - and then what's the advantage of the built-in features of Ada > over and > The advantage of the built-in features are that they are a very good implementation of a tasking model. You seem to have two standards. C is good because you can do what you want while Ada is bad because it does not do everything for you. > > How, using C or C++, would you create a threaded program and > > ensure that signals are handled by a specified thread, and not > > simply by the thread that is currently running when the signal > > is received? > > What do you mean "handled by a thread"? How can you distinguish which > thread is actually interrupted? More importantly, why do you care? I mean, how do you determine which thread actually does the actions to respond to a signal? Signals are asynchronous. You cannot predict which thread will be executing when the signal is received. You can determine which thread does the work of responding to a signal. Ada treats signals (or, as they call them, interrupts) as a form of asynchronous thread communication. Since Ada 95, all Ada interrupt handling has been handled in the following manner. A protected object is created to receive the interrupt. Ada provides pragmas to designate the protected object as an interrupt receiver, and to associate a particular signal with the protected object. You typically want a protected object with a parameter-less procedure and an entry. protected handler is procedure Set; entry Release; pragma Interrupt_Handler(Set); pragma Attach_Interrupt(Set, SIGINT); private Counter : Natural := 0; end handler; protected body handler is procedure Set is begin Counter := Counter + 1; end Set; entry Release when Counter > 0 is begin Counter := Counter - 1; end Release; end handler; Using the example above: A task is created to handle the interrupt. That task calls Release and is suspended because the condition evaluates to FALSE. When the designated signal is received the procedure Set is called, causing Counter to be incremented. This immediately changes the condition on the Release entry, causing the counter to be decremented and the suspended task to be scheduled. This ensures that only the task I have designated actually handles the interrupt, and that the interrupt handling behaves exactly like any other task in the system. > > However, in POSIX, you can do it by using pthread_sigmask() to disable > delivery of the signal to all threads other than the handling one. > > > You seem to assume that Ada only allows you to use features > > provided by the language while preventing you from creating > > your own features. That idea just doesn't make any sense. > > Nope, I didn't say that - what I said was that Ada (particularily the > concurrent part of Ada) is fairly retarted, particularily if you want to > get performance. In fact, to get the performance similar to that which > can be obtained in C, one would pretty much have to write in the C > subset of Ada [i.e. turn off most of the checking, use libraries written > in C + asm]. And even there I'd have my doubts - given the additional > features that Ada compilers have to deal with, I doubt that they would > have focused as much on the optimizations. Interesting. Ada compilers written for a POSIX compliant system usually implement concurrency through the POSIX libraries. Ada compilers written for other systems, such as WIN32 implement their concurrency using the thread libraries native to that system. It is extremely easy to call C libraries from an Ada program. The primary advantages of the Ada approach are that concurrency is implemented natively when the OS supports threads, and the Ada source code is highly portable from one system to the other. The only non-portable features will be the names of interrupts across systems. > > Linked lists are not implemented as native syntax in either > > Ada or C, yet they are used frequently in both languages. > > How can that be? > > And their C implemenations are faster. Is that true in all cases? I suspect not. For instance, I responded to a thread on Comp.Programming concerning an algorithm to identify the first bit set in a 32 bit integer. My Ada solution, in its worst case, runs in about 3 microseconds on a WIN XP system, and I do a linear search of the bits. Jim Rogers