CVS difference for ai05s/ai05-0275-1.txt
--- ai05s/ai05-0275-1.txt 2012/03/10 05:10:51 1.3
+++ ai05s/ai05-0275-1.txt 2012/03/10 05:23:44 1.4
@@ -1,6 +1,7 @@
!standard C.6(16) 12-02-25 AI05-0275-1/03
!class binding interpretation 11-11-09
!status Amendment 2012 11-12-27
+!status ARG Approved 10-0-0 12-02-25
!status work item 12-02-13
!status ARG Approved 7-0-2 11-11-12
!status work item 11-11-09
@@ -50,22 +51,26 @@
{an atomic}[a volatile] object {may require}[should involve] the use of an appropriate
memory barrier.
-!discussion
+Add the following AARM Discussion:
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. For volatile variables, C.6(16) additionally
-specifies that all tasks see the same order of updates.
+will ever see partial updates of any variable. For volatile variables (including atomic
+variables), the above rule additionally specifies that all tasks see the same order of updates.
If for a shared variable X, a read of X occurs sequentially after an update of X, then the
-read will return the updated value if X is volatile, but may or or may not return the updated
-value if X is non-volatile. For non-volatile accesses, a signaling action is needed in order
-to share the updated value.
+read will return the updated value if X is volatile or atomic, but may or or may not return
+the updated value if X is nonvolatile. For nonvolatile accesses, a signaling action is
+needed in order to share the updated value.
-Because accesses to the same atomic variable by different tasks establishes a sequential order
+Because accesses to the same atomic variable by different tasks establish a sequential order
between the actions of those tasks, implementations may be required to emit memory barriers
around such updates or use atomic instructions that imply such barriers.
+!discussion
+
+See the AARM notes above.
+
!example
The example given in AI05-0117-1 is wrong, as it does not require sequential access to
@@ -166,7 +171,7 @@
needed between two atomic accesses and between any atomic access and
an access to a (potentially) shared variable by the same task.
A barrier may be needed between an atomic access and an access of a
-shared non-volatile variable, to ensure that either the old or the
+shared nonvolatile variable, to ensure that either the old or the
new value will be read, see 9.10(15b). A typical implementation would
emit full barriers before and after atomic reads and writes, eliding
consecutive barriers without intervening shared variable accesses.
Questions? Ask the ACAA Technical Agent