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.