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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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 Received: by 10.68.189.194 with SMTP id gk2mr12937591pbc.3.1323789808974; Tue, 13 Dec 2011 07:23:28 -0800 (PST) Path: lh20ni18135pbb.0!nntp.google.com!news2.google.com!postnews.google.com!m7g2000vbc.googlegroups.com!not-for-mail From: Ada BRL Newsgroups: comp.lang.ada Subject: Re: Interrupts handling in ADA Date: Tue, 13 Dec 2011 07:23:28 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <30143086.6.1323549838421.JavaMail.geo-discussion-forums@vbbfq24> <6df577eb-9c6a-4f82-95e4-817f6ad1ba6e@r6g2000yqr.googlegroups.com> NNTP-Posting-Host: 164.11.203.58 Mime-Version: 1.0 X-Trace: posting.google.com 1323789808 20293 127.0.0.1 (13 Dec 2011 15:23:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 13 Dec 2011 15:23:28 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m7g2000vbc.googlegroups.com; posting-host=164.11.203.58; posting-account=yig7mwoAAAAAcduNbH7Dpal1sjCSAijA User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUARELSCNK X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2,gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2011-12-13T07:23:28-08:00 List-Id: On 13 Dic, 15:07, Simon Wright wrote: > Ada BRL writes: > > On 10 Dic, 22:27, Simon Wright wrote: > >> The spec might look like > > >> =A0 =A0with Ada.Containers.Vectors; > >> =A0 =A0package Queueing is > >> =A0 =A0 =A0 type Message is new Integer; > >> =A0 =A0 =A0 package Queue_Data > >> =A0 =A0 =A0 is new Ada.Containers.Vectors (Index_Type =3D> Natural, > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Element_Type =3D> Message); > >> =A0 =A0 =A0 protected Queue is > >> =A0 =A0 =A0 =A0 =A0procedure Put (M : Message); > >> =A0 =A0 =A0 =A0 =A0entry Get (M : out Message); > >> =A0 =A0 =A0 private > >> =A0 =A0 =A0 =A0 =A0Buffer : Queue_Data.Vector; > >> =A0 =A0 =A0 end Queue; > >> =A0 =A0end Queueing; > > >> and (as a hint) the body of the Get entry might start like > > >> =A0 =A0 =A0 entry Get (M : out Message) when not Buffer.Is_Empty is > >> =A0 =A0 =A0 begin > > Thank you for the reply! > > > Please tell me if I'm wrong: > > > - inside the main task I must use an accept statement "Get": by doing > > Nitpicks: I said 'main task', but you might not need an explicit task, > because the main program runs in the context of the 'environment task' > so can make tasking calls, be blocked etc just like any other task. Ok, it's clear, the main function it's a task itself... > > Also, this isn't called an accept statement; it's an entry call. The way > a task indicates it's prepared to accept an entry call is by an accept > statement; protected objects are different. So if instead of Queue being > protected it was a task (not something I'd recommend) the corresponding > body part would have looked like > > =A0 =A0accept Get (M : out Message) when not Buffer.Is_Empty do I haven't understood you... What does it mean "declaring a protected task"? You would not recommend it, ok, but what does it mean? In the example above is the Buffer (member of main) the unique protected object or the main function itself has to be declared as protected? Sorry but I'm beginning to loose the thread... > > > it, this means that the main task wait on this "barrier" until there > > is something inside the protected object queue; when entry Get is > > available (due to the incoming data), the main task is automatically > > notified and it executes the Get function, isnt' it? So the entry / > > accept paradigm is something like events in C? > > So the main task doesn't has to constantly poll the queue; the entry / > > accept statement do it by itself. Am I right? > > That's right (no comment on the 'events in C' part, though).