CVS difference for ai05s/ai05-0275-1.txt

--- ai05s/ai05-0275-1.txt	2012/02/14 03:57:53	1.2
+++ ai05s/ai05-0275-1.txt	2012/03/10 05:10:51	1.3
@@ -1,4 +1,4 @@
-!standard C.6(16)                                     12-02-13  AI05-0275-1/02
+!standard C.6(16)                                     12-02-25  AI05-0275-1/03
 !class binding interpretation 11-11-09
 !status Amendment 2012 11-12-27
 !status work item 12-02-13
@@ -52,37 +52,19 @@
 
 !discussion
 
-C.6(16/3) is not about sequential actions at all, but rather about the view of
-updates that tasks have of the objects. The updates (especially of objects with
-multiple parts) may occur in any order, but all tasks will see the same order.
-In particular, it cannot be the case that task T1 sees the new version of part 1
-of a volatile object V and the old version of part 2 of V, while task T2 sees
-the old version of part 1 of V and the new version of part 2 of V. Any other
-view of old and new versions of V is allowed (in the absence of other
-synchronization, of course).
-
-[*** Editor's note: Geert Bosch objects to the above discussion, and gives a
-very different model of what Volatile means. See the e-mail of December 30th. I
-actually prefer it to the wording in the Standard, but cannot derive his model
-from anything in the Standard. Most importantly, his higher-level model offers
-the possibility of describing the meaning of Volatile in semantic terms, which
-would be a big improvement over the current version of C.6(16/3). He, OTOH,
-seems content with C.6(16/3), but perhaps that's because he isn't planning on
-paying any attention to it. :-) ***]
-
-
-Memory barriers are only needed between sequential actions involving shared variables.
-A typical way to ensure this is emit the memory barriers on accesses to atomic objects;
-this is what we suggest in the implementation note.
-
-However, memory barriers may be required any time sequential actions are required for
-access to shared variables (of any category, including "normal" objects). In particular,
-protected actions and actions that signal another also may need barriers, or associated
-access to shared variables need the barriers. We do not try to determine any advice to
-give implementers in these other cases, because their implementation may vary wildly.
-For instance, some of these actions may require a call to an OS service. Others may be
-modeled as an atomic object (such as the spin lock of a protected action) and thus need
-no special effort.
+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.
+
+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.
+
+Because accesses to the same atomic variable by different tasks establishes 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.
 
 !example