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,6349d4dc47b70bc0 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Basic critical sections question Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <71385df3-5fec-49b9-9d7a-98cb95a346ed@n20g2000prc.googlegroups.com> Date: Sun, 4 Jul 2010 09:58:14 +0200 Message-ID: <956zf5tr9bot$.y93a7tm5bbu5.dlg@40tude.net> NNTP-Posting-Date: 04 Jul 2010 09:58:15 CEST NNTP-Posting-Host: d0b4c111.newsspool1.arcor-online.net X-Trace: DXC=V\m4H11EZgnm7>ihJR;B_cic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbE>BTRb^`4fk[6LHn;2LCVn[ On Sat, 3 Jul 2010 13:06:24 -0700 (PDT), usenet@scriptoriumdesigns.com wrote: > Suppose I have a multi-tasking system where different tasks may > execute a sequence like > > P1(A,B); > P2(C,D); > P3(E,F); > > and I want to make this sequence a critical section. What is the > typical Ada way to do this? I depends on the nature of P1..P3 > Would I wrap P1, P2 and P3 in a protected > object and call as follows (perhaps creating a record to hold A..F to > make things a bit cleaner)? > > PO.P(A,B,C,D,E,F); > > Or if not that, what? There are many ways and solutions, starting with better design. What are A,B,C,D,E,F. They might be made objects or put into object maintaining their invariants when accessed concurrently. At the low level there are four major approaches: 1. Protected operation. Used when what you do is short and non-blocking. E.g. P1 cannot do I/O. 2. Monitor task performing desired actions. This one can perform lengthy or blocking operations. 3. Mutexes (implemented by a protected object, mutex holder is wrapped into a controlled object). The mutex holder when constructed seizes the mutex and releases it upon finalization. While the holder exists you execute the desired actions. 4. Asynchronous monitor task. That is when you start actions entering a rendezvous with the monitor. Then you leave the rendezvous and do something else, while the monitor is busy executing the actions. Some time later you engage another rendezvous to make sure that the monitor task finished the work. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de