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,4fe1e6b66c35dfe2 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: About task-safeness Date: Thu, 3 Feb 2011 18:33:00 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <06ecb5ab-a9e5-4a5d-9370-6bbe137d3693@glegroupsg2000goo.googlegroups.com> <8qv8neF9i0U1@mid.individual.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1296779582 22753 69.95.181.76 (4 Feb 2011 00:33:02 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 4 Feb 2011 00:33:02 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Xref: g2news2.google.com comp.lang.ada:17827 Date: 2011-02-03T18:33:00-06:00 List-Id: "Niklas Holsti" wrote in message news:8qv8neF9i0U1@mid.individual.net... > Randy Brukardt wrote: ... >> Note that "protection" may simply be declaring the object Atomic. >> Presuming the compiler supports that, there isn't a problem with multiple >> tasks accessing the same counter. > > Randy, could you be more explicit about your suggested use of Atomic? As I > understand it, even if a counter variable N is Atomic, two tasks > concurrently executing an assignment of the form > > N := N + 1; > > can interleave their actions so that N is increased by only 1, not by 2 as > intended. Good point. All of the examples I've used have been where one task set the value to some constant (like True or False), and other read it. That's safe, while doing both may not be. Practically(*), however, this will be generated atomically on an x86 (at least on Janus/Ada): it will generate an Inc [N] instruction, which I don't think can be interupted between the read and the write. The net effect is that the operation will be undivided on a single processor. (I don't really know how multicore systems might affect this; there may be additional locks needed here.) (*) Note that Ada language rules might make generating this atomically impossible, such as if an overflow check is needed. In that case, separate read and write instructions might be needed. That's not a problem in the Janus/Ada runtime (where checks are suppressed always, mostly for size and speed reasons), but it might be in your code. And of course, this is very target dependent. N := N + A; is much harder to generate atomically, and expressions involved atomic array components might be impossible. Randy. P.S. None of this actually depends on "Atomic" in the current Janus/Ada compiler, as it isn't actually supported. But this optimization is done for all objects. In addition, Janus/Ada currently treats all writes as volatile. Most likely, the next version of Janus/Ada will have a full implementation of Atomic (it's been fully implemented in the front end for years - Isaac did it as part of an ACATS review contract back in the mid-90s. But I never implemented it in the optimizer and back-end - and that needs to be fixed.)