Version 1.1 of acs/ac-00238.txt

Unformatted version of acs/ac-00238.txt version 1.1
Other versions for file acs/ac-00238.txt

!standard E.2.1          12-11-21 AC95-00238/00
!class confirmation 12-11-21
!status received no action 12-11-21
!status received 12-07-27
!subject Aliased variables in Shared_Passive packages?
!summary
From: Erhard Ploedereder Sent: Friday, July 27, 2012 8:39 AM
AARM C.6. (16.b/3) says: ----------- Discussion: {AI05-0275-1} From 9.10 it follows that (in non-erroneous programs) accesses to variables, including those shared by multiple tasks, are always sequential. This guarantees that no task will ever see partial updates of any variable. ------------
I do not see how this follows.
On the contrary, the last sentence directly contradicts 9.10 (11), where one is (indirectly) told that one WILL be able to see partial updates, unless the updates/reads of shared variables are properly synchronized. So the last sentence certainly only applies to non-erroneous programs, not to any and all accesses.
The reason why I do not see how the first part follows is that 9.10 defines when two actions are sequential in 9.10(11). None of the three bullets applies when two tasks access a shared variable that is neither atomic nor volatile. So where does this cited conclusion come from? And if there is no basis for the conclusion, it should not be here.
Actually: The cited Discussion would be true if "atomic" were inserted in front of both occurrences of "variable(s)". Which is probably the intent of the discussion anyway, since the whole section deals in atomic and volatile variables, not in general shared variables.
***************************************************************
From: Bob Duff Sent: Friday, July 27, 2012 10:42 AM
> I do not see how this follows.
Well, every statement about some property of the Ada language can only be understood if you add an implicit "unless it's erroneous".
By the way, the wording you quoted, "in non-erroneous programs" is slightly wrong, because erroneous is not a property of programs, but of program executions. A program execution can be non-erroneous today, but erroneous tomorrow when you run it with different input data.
***************************************************************
From: Erhard Ploedereder Sent: Friday, July 27, 2012 11:12 AM
> Well, every statement about some property of the Ada language can only > be understood if you add an implicit "unless it's erroneous".
I could buy that for the content of the last sentence. But what about the justification of the first sentence? (and without that one, the last sentence does not hold at all, even for non-erroneous executions)
***************************************************************
From: Geert Bosch Sent: Friday, July 27, 2012 2:46 PM
> On the contrary, the last sentence directly contradicts 9.10 (11), > where one is (indirectly) told that one WILL be able to see partial > updates, unless the updates/reads of shared variables are properly synchronized. > So the last sentence certainly only applies to non-erroneous programs, > not to any and all accesses.
Right, the whole point is that if execution is non-erroneous one cannot see partial updates of variables.
> The reason why I do not see how the first part follows is that 9.10 > defines when two actions are sequential in 9.10(11). None of the three > bullets applies when two tasks access a shared variable that is > neither atomic nor volatile. So where does this cited conclusion come > from? And if there is no basis for the conclusion, it should not be here.
Indeed, one has to ensure two accesses to shared variables are sequential, e.g. by using atomic variables, protected actions or similar.
Consider the following:
Shared_Variable : Long_Long_Integer := -1; pragma Volatile (Shared_Variable); Atomic_Flag : Boolean := False; pragma Atomic (Atomic_Flag);
task 1:
Shared_Variable := Shared_Variable + 1; Atomic_Flag := True;
task 2: if Atomic_Flag = True then pragma Assert (Shared_Variable = 0); else null; -- Any access of Shared_Variable would be erroneous here end if;
All accesses of the Atomic_Flag are sequential. So, the read of Atomic_Flag by Task 2 either comes before or after the write by Task 1. If the flag is read as True, that access came sequentially after the write. All actions in a task are sequential as well, so the accesses to Shared_Variable by task 2 comes after the accesses by task 1. So, the execution is not erroneous and the assertion holds. Do you agree?
***************************************************************
From: Robert Dewar Sent: Friday, July 27, 2012 3:51 PM
> All accesses of the Atomic_Flag are sequential. > So, the read of Atomic_Flag by Task 2 either comes before or after the > write by Task 1. If the flag is read as True, that access came > sequentially after the write. All actions in a task are sequential as > well, so the accesses to Shared_Variable by task 2 comes after the > accesses by task 1. So, the execution is not erroneous and the > assertion holds. Do you agree?
I agree, given the pragma Volatile, without the pragma Volatile, this would not be the case.
***************************************************************
From: Erhard Ploedereder Sent: Monday, July 30, 2012 5:18 AM
I certainly agree with your example.
I was afraid that somewhere out of 16.b/3 there would loom a spectre that would allow dropping the pragmas and still require the expected semantics.
By now, I have realized that the first sentence of 16.b/3 is but a resolution-based restatement of 9.10(11), not something that requires derivation from rules of sequentiality.
My< problem was/is that there is also an implementation-based notion of sequentiality, created by the memory bus. Make Shared_Variable word-sized Integer. Drop the Atomic pragmas. In the implementation sense, the accesses are still "sequential" (when executed at all) -- luckily they are not in Ada, so the program turns erroneous.
The "This guarantees for all..." simply threw me off track.
Let it rest in peace (even if I still think that the addition of "atomic" in 16.b wording would make the idea much clearer and would not even have to talk about non-erroneousness ;-) )
***************************************************************
From: Randy Brukardt Sent: Monday, July 30, 2012 2:25 PM
Will do, but note that adding "atomic" would eliminate the point of the paragraph, which is that in non-erroneous programs, all accesses to shared variables are sequential (and specifically, accesses to volatile variables are sequential). The paragraph was constructed in response to various earlier attempts to understand the rules in terms of seeing partial updates of volatile variables in the same order in each task -- but that's irrelevant as such accesses are erroneous.
I was trying to figure out a way to make the point clearer, but I'm happy to "let it rest in peace".
***************************************************************

Questions? Ask the ACAA Technical Agent