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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 2002:a37:4a85:: with SMTP id x127mr189317qka.152.1587588079760;
        Wed, 22 Apr 2020 13:41:19 -0700 (PDT)
X-Received: by 2002:a9d:6016:: with SMTP id h22mr842904otj.206.1587588079471;
 Wed, 22 Apr 2020 13:41:19 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!peer02.am4!peer.am4.highwinds-media.com!news.highwinds-media.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!feeder1.cambriumusenet.nl!feed.tweak.nl!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 13:41:19 -0700 (PDT)
In-Reply-To: <hgbf8aFcbk1U1@mid.individual.net>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=185.22.143.251;
 posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf
NNTP-Posting-Host: 185.22.143.251
References: <ly1rofhhyf.fsf@pushface.org> <hgbf8aFcbk1U1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c246151d-600a-4262-a7ee-e6233a344333@googlegroups.com>
Subject: Re: Scheduling behaviour issue
From: AdaMagica <christ-usch.grein@t-online.de>
Injection-Date: Wed, 22 Apr 2020 20:41:19 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2551
X-Received-Body-CRC: 692914363
Xref: reader01.eternal-september.org comp.lang.ada:58467
Date: 2020-04-22T13:41:19-07:00
List-Id: <comp.lang.ada>

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):

<quote>
For the actions performed by a program that uses shared variables, the following assumptions can always be made:

* If between two synchronization points of a task, this task reads a shared variable whose type is a scalar or access type, then the variable is not updated by any other task at any time between these two points.

* If between two synchronization points of a task, this task updates a shared variable whose type is a scalar or access type, then the variable is neither read nor updated by any other task at any time between these two points. 

The execution of the program is erroneous if any of these assumptions is violated.
</quote>

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. This is one of the reasons I guess that protected objects were introduced.