Re: Scheduling behaviour issue

[Jere <jhb.chat@gmail.com>]

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.
> 
> <SNIPPED>
>
> 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).