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,bdf72b2364b0da13 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.75.170 with SMTP id d10mr6246863pbw.6.1323790780495; Tue, 13 Dec 2011 07:39:40 -0800 (PST) Path: lh20ni18171pbb.0!nntp.google.com!news1.google.com!goblin3!goblin.stu.neva.ru!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interrupts handling in ADA Date: Tue, 13 Dec 2011 16:39:45 +0100 Organization: cbb software GmbH Message-ID: References: <30143086.6.1323549838421.JavaMail.geo-discussion-forums@vbbfq24> <1f0ump3yhi731$.1gh4827ra0a87.dlg@40tude.net> <7a17c1d0-30dd-47b8-a800-3575a8793fbe@d10g2000vbf.googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2011-12-13T16:39:45+01:00 List-Id: On Tue, 13 Dec 2011 06:51:25 -0800 (PST), Ada BRL wrote: > On 13 Dic, 14:04, "Dmitry A. Kazakov" > wrote: >> On Tue, 13 Dec 2011 05:11:14 -0800 (PST), Ada BRL wrote: >>> On 11 Dic, 09:23, "Dmitry A. Kazakov" >>> wrote: >>>> On Sat, 10 Dec 2011 12:43:58 -0800 (PST), Ada @ BRL wrote: >>>>> The environment of ADA applcation is: >>>>> I have 4 tasks that execute at the same time: >>>>> one is the main task, >>>>> the other three execute a "read" from network (socket) function inside >>>>> their bodies (on the other side there's the C/C++ application with 3 >>>>> network sockets). >>>>> [I decided to use the sockets instead of dll/lib import because this approach hasn't worked... =( ] >> >>>> What dll import has to do with sockets, except that sockets usually are >>>> provided by a library? >> >>> I would have liked to use dll import to exchange data between C stuff >>> and Ada program instead of using two programs (C and Ada) >>> communicating through sockets... >> >> You can link to an import library from Ada without any problems. Which OS >> are you using? > > Windows 7 64 bit, Home Premium SP1 ... > I have tried in many ways to import symbols but it was impossible... > I had a linker error: couldn't find exported symbols... > I've copied the dll into all the possible folder of my project. No, you link to the import library, that is *.lib, not *.dll. It is also possible to load dynamically using LoadLibrary etc. Both works perfectly well and simple with GNAT. The simplest way is to create a gpr-file for the external library and include it into your Ada project using "with." GNAT knows what to do next. >> No, OS event objects and entry calls assume that the recipient is inactive >> and thus is ready to accept the notification. That is a non-preemptive >> model. > > Does this means that the main task has to be in wait for event state > (blocked and so NOT running)? Yes, if the main task is the subscriber. If you look at how GUI's are built, they do exactly this: run the messages/events/signal processing loop, which does nothing when there is no messages/events/signals. >> Software interrupts are preemptive. An interrupt breaks the execution of >> the recipient. Like with exceptions there are two models of what happens >> after interrupt has been serviced: continuation back from the point where >> the task was interrupted vs. winding up the stack and aborting some stuff >> with continuation from a definite point. AST's are usually like former, >> Ada's ATC are like latter. > > Sorry what does ATC stand for? Asynchronous Transfer of Control. >> the task was interrupted vs. winding up the stack and aborting some stuff >> with continuation from a definite point. AST's are usually like former, >> Ada's ATC are like latter. > > I haven't understood well... > > With entry / accept will I use AST or ATC? ATC in Ada is like this (example from the language manual): select Terminal.Wait_For_Interrupt; Put_Line("Interrupted"); then abort -- This will be abandoned upon terminal interrupt Put_Line("-> "); Get_Line(Command, Last); Process_Command (Command (1..Last)); end select; You have some piece of code executing (between abort and end select) while waiting for some event (the entry call right after select). When event happens, the code is aborted and you go to the part Put_Line("Interrupted"); BUT: Just don't worry about ATC, it is not a good idea to use it, almost always. > if I have this piece of code inside main task body: > > do stuff before; > accept event; > do stuff after; A more complete picture is: do stuff before; accept event do do stuff upon rendezvous; end; do stuff after; > The main thread is blocked onto "event" barrier, when socket calls > Main.event it can continue and perform "do stuff after". > > Code of socket body: > > do stuff before; > Main.event; > do stuff after; > > Does the socket continue its execution after calling to Main.event, in > parallel with main task or will it be blocked until the main task > blocks itself again onto a barrier? When the socket task calls an entry of the main task, it is blocked until the main task accepts the call. There is a queue of calls to each entry, so multiple tasks can await there for a rendezvous. At a time only one rendezvous is accepted and the corresponding task call is removed from the queue. Then both tasks engage the rendezvous. Upon the rendezvous the code "do stuff upon rendezvous" is executed. Any exceptions in this code propagate into both tasks. When the code completes this or that way the rendezvous ends, and both tasks continue their execution independently on each other. I.e. concurrently executing "do stuff after." Here is a diagram: Main Socket task | | do stuff before do stuff before; | | accept call \ / do stuff upon rendezvous (synchronously) / \ do stuff after; do stuff after | | Consider the rendezvous code executed as if both tasks were one. > Please tell me if I'm not right: every task append it's event > (data_arrived event) onto the queue. Rendezvous are better than that, because the queue contains the tasks themselves. No data are actually copied. If you want to copy data from one task to another, you simply pass them as a parameter of the call and make a copy of the parameter during the rendezvous. > For this reason the main task enters the running state and pops all > the elements of the queue (events); after having processed all the > events it will enter the blocked state again. Am I right? Yes. A task can wait for multiple entries (see the select statement). If all alternatives of the select are closed, the task is blocked. The simplest case is just one accept. The task is blocked until nobody calls to the entry. >>>> 3. "Queue": socket readers enqueue some data (the queue is implemented >>>> using a protected object). Other tasks (there could be many) dequeue data >>>> and do something meaningful with them. There are many kinds of queues for >>>> different purposes and of different behavior. > > Is it the same of using Mailbox? Yes, mailbox is a sort of queue. But there are queues of different flavors. E.g. blocking, non-blocking, waitable on the ends, queues of different policies at their ends, blackboards etc. > Roughly speaking, are you suggesting me not to copy the data from > sockets but accessing the same data through "pointers"? Not necessarily pointers. I don't know why socket tasks cannot process their data concurrently. If they need to be synchronized at certain points why not to do just this. It is a balance which depends on the problem at hand. In some cases monitors are preferable in other cases they are not. > Or, are you suggesting me to avoid context switching? That is the next step. The worst case is both to copy data and to switch the context. This is what a queue-based solution [*] would do. The best case is same data same context. BUT, as always, "premature optimization is the root ..." etc. Solve the problem in the simplest way, only if the performance is poor consider other solutions. ----- * Which does not do processing at the context of a protected action. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de