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-Received: by 2002:a0c:e9cc:: with SMTP id q12mr1848077qvo.128.1587602828937; Wed, 22 Apr 2020 17:47:08 -0700 (PDT) X-Received: by 2002:aca:ad52:: with SMTP id w79mr1169003oie.122.1587602828603; Wed, 22 Apr 2020 17:47:08 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 22 Apr 2020 17:47:08 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=70.109.61.2; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 70.109.61.2 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6cd92320-4c1b-4e3e-aa34-c31b54580d2c@googlegroups.com> Subject: Re: Scheduling behaviour issue From: Jere Injection-Date: Thu, 23 Apr 2020 00:47:08 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:58469 Date: 2020-04-22T17:47:08-07:00 List-Id: On Wednesday, April 22, 2020 at 5:58:52 PM UTC-4, Niklas Holsti wrote: > On 2020-04-22 23:41, AdaMagica wrote: > > Am Mittwoch, 22. April 2020 20:03:56 UTC+2 schrieb Niklas Holsti: > >> Under RTEMS, if there are higher-priority tasks on that processor core, > >> such actions on shared data would not have this mutual-exclusion > >> property, and the shared data could be messed up. However, I'm not sure > >> if such use of shared data is "correct" per the Ada RM, and if the > >> resulting mess can be called "misbehaviour". > > > > This is the reasoning of Ada 83 (RM 9.11 Shared Variables): > > [snipped] > > > I'm too lazy to search for the relevant text in current Ada, but as > > far as I can tell, this principle is still valid. > > > > In this connection I want to ask if the "Discussion" in RM 2012 > 9.10(15.b) uses a valid example. The Discussion says that two > "sequential" assignments to the same variable, where neither "signals" > the other, are not erroneous, because there may be cases where the order > in which the assignments are executed makes no difference. The > Discussion gives, as an example, assignments that just "accumulate > aggregate counts". It seems to me that the order of two such assignments > to the same counter does matter, because the values written may be > different, as in the counter-increment example above. Am I right? If so, > this example seems wrong for this Discussion (also in Ada 202X ARM). It's definitely worded awkwardly. The text is correct that it isn't a data race and therefor erroneous, but I think you are correct that there is a potential race condition there where the counter could get incremented to the same value twice, losing a count (assuming I am reading it correctly).