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

Differences between 1.6 and version 1.7
Log of other versions for file ai05s/ai05-0117-1.txt

--- ai05s/ai05-0117-1.txt	2010/11/23 21:47:16	1.6
+++ ai05s/ai05-0117-1.txt	2011/01/25 07:52:10	1.7
@@ -651,3 +651,567 @@
 
 ****************************************************************
 
+From: Santiago Uruena Pascual
+Date: Wednesday, January 12, 2011  2:29 AM
+
+Hello again, and Happy New Year!,
+
+sorry if this is not the adequate channel / way for dicussing Ada Issues, but
+I have further comments about AI05-0117.
+
+While in Java 5.0 it was OK to require inserting memory barriers in volatile
+objects because this language is not meant for writing device drivers (RTSJ
+adds the RawMemoryAccess class for this purpose, though), I think in a systems
+programming language like Ada plain volatile / atomic accesses (with no
+barriers) are a must for hardware interfacing. Probably is better to continue
+with the pragma Coherent solution as in previous version of this AI, which
+would be compatible with the atomic types being developed for the future C++0X
+and C1X standards [1][2][3].
+
+Furthermore, the current proposal is not enough for properly coding wait-free
+algorithms (even in uniprocessor machines): besides coherent loads and stores
+(specifying indivisible accesses, visibility to other threads, and ordering
+from other CPUs), it is also required to provide coherent operations=
+(test-and-set/atomic add/atomic xor/compare and swap...), and to relax memory
+operations (not just sequential consistency which is extremely expensive in
+some arch like Power or ARM [4], but also Acquire / Release / Consume /
+Relaxed semantics like in Java and C++0X / C1X).
+
+Defining the memory model for Java and C/C++ was a huge effort due to the
+subtle memory semantics of different hardware microarchitectures, and bugs are
+still being found in the specifications [4][5]. So as protected objects are
+perfectly OK for SMP/multicpre (the memory barriers are already coded in the
+underlying OS locks), inserting barrier instructions to pragma Volatile /
+Atomic as proposed in the current AI version (rev 1.6) is an incompability
+that would certainly break existing code in some device drivers or interfacing
+with C, and is not enough for programming wait-free algorithms, IMHO maybe is
+better to delay this AI to the next standard revision after Ada 2012. This
+could leverage the experience gained in the standardization and implementation
+of future C / C++ specs, so Ada can have a compatible approach that take
+advantage of the existing implementations and to ease interfacing with the C
+atomic types.
+
+Thanks for your patience, all the best.
+
+Santi
+
+
+References:
+
+[1] "Should volatile Acquire Atomicity and Thread Visibility Semantics?", by
+    Hans Boehm & Nick Maclaren
+    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html
+
+[2] "C++0x November 2010 Working Draft" (chapter 29: Atomic operations library)
+    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3225.pdf
+
+[3] "C1X -- October 2010 Committee Draft" (section 7.17: Atomics)
+    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1516.pdf
+
+[4] "Mathematizing C++ Concurrency", by Mark Batty et al.
+    http://www.cl.cam.ac.uk/~pes20/cpp/test.pdf
+
+[5] "On Validity of Program Transformations in the Java Memory Model",
+    by Jaroslav Sevcik & David Aspinall
+    http://homepages.inf.ed.ac.uk/s0566973/jmmtrans.pdf
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, January 12, 2011  3:29 PM
+
+> sorry if this is not the adequate channel / way for dicussing Ada
+> Issues, b= ut I have further comments about AI05-0117.
+
+The ARG is discussing this (again) privately. The early consensus is that we
+have it right in the current AI05-0117-1.
+
+The (previous) decision reflected in the current write-up of AI05-0117-1 is that
+it is premature to go beyond the existing Ada pragmas. Processor and memory
+architectures are rapidly evolving, and it seems unlikely that there is a
+general solution that will work now and in the future. We don't want Ada to be
+burdened with obsolete features. So this is best left for Ada 2020 when we
+should be able to clearly see what is needed (pun intended).
+
+One thing that we did notice is that some people were misreading the intent of
+the current language for Volatile. Therefore, we reworded that definition to
+match the actual intent (from what we can tell, implementations have implemented
+the real intent and not the stricter reading that some readers have had). We
+don't expect this wording change to have any impact on actual implementations,
+or on how programs work.
+
+There is nothing stopping an implementation from providing additional facilities
+if needed for a particular target system. Indeed, the provision of such features
+would provide an example of an approach to use in future Ada standards.
+
+The above is heavily colored by my own opinions on this topic, and should not be
+taken as an "official" pronouncement. Only the contents of AIs and (ultimately)
+the Ada standard can do that.
+
+****************************************************************
+
+From: Alan Burns
+Date: Wednesday, January 12, 2011  7:48 AM
+
+It seems that our view that weakening the definition of volatile would suffice
+is not supported by everyone. Shall I try and discuss this topic further with
+Santi?
+
+[Followed by a reposting of the Ada-Comment message sent at 2:29 AM - Editor.]
+
+****************************************************************
+
+From: Bob Duff
+Date: Wednesday, January 12, 2011  1:18 PM
+
+Sounds like a good idea to me.  The Java and C++ folks have apparently been
+doing a lot of work in this area, so it would be a good idea for at least some
+folks on ARG to pay attention to it.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, January 12, 2011  1:25 PM
+
+Let's not spend TOO much effort on this, anything we do won't have much effect
+on any implementations I suspect (certainly GNAT will just borrow whatever is
+provided by the gcc back end, which presumably is the same as what the C
+standard has now).
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, January 12, 2011  1:49 PM
+
+I think we all pretty much felt that the new wording did a better job of
+capturing what implementations already did, or at least what was the original
+intent.  The subtleties that Santi is mentioning seem worth investigating, but I
+wonder whether any implementation intends to make any real changes as a result
+of this new wording.  Do you think that the old wording was better in some way?
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, January 12, 2011  1:56 PM
+
+I know that GNAT ignores what the RM says and assumes that
+
+a) volatile means the same as in C
+
+b) C has it right
+
+:-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, January 12, 2011  3:15 PM
+
+AI05-0117-1 already says that no change is intended. Beyond that, we already
+have agreement on what to do (which is make the RM say what we meant and what is
+actually implemented, and go no further). I would very much doubt that we would
+get any support for doing more.
+
+I know we wouldn't get such support from me. Processor and memory architectures
+change frequently, and it would be a huge mistake to standardize features that
+depend on a particular architecture that probably will get replaced by something
+better in the next few generations. If processor vendors continue on their path
+to thousands of cores, I suspect that cache coherence will simply become
+impossible to implement, and anything that depends on it simply will not work.
+So I don't want to make any silly requirements in the Ada standard, either by
+mistake (as with the current wording) or by some sort of new features.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, January 12, 2011  3:22 PM
+
+As a pragmatic point, hooking ourselves to whatever C decides makes good sense
+:-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, January 12, 2011  3:39 PM
+
+Right. And trying to guess ahead of time what they are going to decide is a
+fool's game. It almost certainly would lead to junk in the Ada Standard. Not
+worth it.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, January 12, 2011  3:53 PM
+
+Could we just reference the ISO C standard? :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, January 12, 2011  4:06 PM
+
+We could, but we'd probably have a versioning problem. That is, we probably want
+to use the *next* version of the C standard for this purpose, not the current
+one. But we wouldn't have a way to do that until that version is decided. And if
+we used the current version, Ada would then be behind when C gets updated.
+
+[Yes, I noticed the smiley. But I was semi-seriously thinking the same way
+myself, and thus thought that the implications of doing so would be worth
+considering.]
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, January 12, 2011  5:20 PM
+
+Well that's a problem that would only concern language lawyers. The version of C
+referenced is actually totally irrelevant (to all but aforementioned language
+lawyers). The point is that if we did this xref, we would clearly indicate our
+intent to be the same as C, which is the important message.
+
+****************************************************************
+
+From: Bob Duff
+Date: Wednesday, January 12, 2011  6:59 PM
+
+> Right. And trying to guess ahead of time what they are going to decide
+> is a fool's game. It almost certainly would lead to junk in the Ada
+> Standard. Not worth it.
+
+I think it's unwise to rely on the C standard.
+It is hopelessly ill-defined in the area of "volatile".
+I don't know if they're planning to fix that for C1X, but as far as I can tell,
+hardly anybody implements even the full C99 standard.
+
+Has anybody on ARG even read what the C standard says?
+If not, it hardly makes sense to blindly agree with it.
+
+Perhaps C++ or Java standards would be more fruitful.
+I don't know, but those folks appear to think about this area.
+
+> I know that GNAT ignores what the RM says and assumes that
+>
+> a) volatile means the same as in C
+>
+> b) C has it right
+
+I think you need to replace "C" with "the gcc dialect of C"
+for the above to be true.  Nothing wrong with GNAT following gcc, here, but gcc
+/= C.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Wednesday, January 12, 2011  7:12 PM
+
+> I think it's unwise to rely on the C standard.
+> It is hopelessly ill-defined in the area of "volatile".
+> I don't know if they're planning to fix that for C1X, but as far as I
+> can tell, hardly anybody implements even the full C99 standard.
+
+Who really cares? I think it is a waste of time for Ada language lawyers to
+think they can do better than the C folks in this area.
+
+> Has anybody on ARG even read what the C standard says?
+> If not, it hardly makes sense to blindly agree with it.
+
+it makes even less sense to try to spin our own definition.
+
+>> I know that GNAT ignores what the RM says and assumes that
+>>
+>> a) volatile means the same as in C
+>>
+>> b) C has it right
+>
+> I think you need to replace "C" with "the gcc dialect of C"
+> for the above to be true.  Nothing wrong with GNAT following gcc,
+> here, but gcc /= C.
+
+Agaibn, only a language lawyer cares about this issue, to me it is a waste of
+time. If you try to come up with a "really good correct definition" of volatile
+
+a) implementors will ignore it
+
+b) so will everyone else
+
+So you will have wasted your time.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, January 12, 2011  8:48 PM
+
+I'm not convinced that only language lawyers care about this issue.  People who
+write device drivers or interrupt/signal handlers in C or Ada care about the
+meaning of volatile. Also, those who use setjmp/longjmp in C/C++ care about
+volatile, since only volatile variables are guaranteed to preserve their value
+across setjmp/longjmp.
+
+I think the big problem with the C and C++ standards is that they don't deal
+with multiple threads, but instead talk about what is true at "sequence" points,
+when you enter a signal handler, and when you do a longjmp. Furthermore, there
+is a presumption you are talking about a single processor executing a single C
+or C++ program.
+
+I think the upcoming standards may start to talk about multiprocessors, but the
+older ones don't address the issue at all.
+
+So I recommend we avoid referring to the C/C++ standards for this purpose in
+anything normative.  I see no harm in adding some kind of implementation advice
+that encourages consistency with the C/C++ definition of "volatile," as it
+evolves.
+
+****************************************************************
+
+From: Ben Brosgol
+Date: Wednesday, January 12, 2011 11:36 PM
+
+Here's the C# approach, as a data point in how languages treat volatile:
+
+(From C# 4.0 Language Specification, Section 10.5.3) << For volatile fields,
+[certain] reordering optimizations are restricted:
+
+* A read of a volatile field is called a _volatile read_. A volatile read has
+  "acquire semantics"; that is, it is guaranteed to occur prior to any
+  references to memory that occur after it in the instruction sequence.
+
+* A write of a volatile field is called a _volatile write_. A volatile write has
+  "release semantics"; that is, it is guaranteed to happen after any memory
+  references prior to the write instruction in the instruction sequence.
+ >>
+
+As noted by Albahari & Albahari, "C# 4.0 in a Nutshell", pp. 829, these rules
+can give counterintuitive results because they allow the compiler to swap a
+write with a subsequent read.  The following example, attributed to Joe Duffy,
+illustrates the problem:
+
+class IfYouThinkYouUnderstandVolatile{
+   volatile int x, y;
+
+   void Test1(){  // Executed on one thread
+      x = 1;      // volatile write to x
+      int a = y;  // volatile read from y
+      ...
+   }
+
+   void Test2(){  // Executed on another thread
+      y = 1;      // volatile write to y
+      int b = x;  // volatile read from x
+      ...
+   }
+}
+
+With C# semantics, variables a and b may both end up with the value 0 -- ie, the
+compiler may interchange the order of the assignment statements in each method
+-- even though both fields x and y are specified as volatile.
+
+In light of such surprises (well to most programmers the above result would be a
+surprise), Albahari & Albahari's advice was to avoid using the volatile keyword.
+
+(Last summer at the AdaCore company meeting I showed the Ada version of this
+example to some ARG members -- Bob Duff and Steve Baird and a few others -- I've
+forgotten what they thought an Ada compiler was allowed to do :-)
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, January 13, 2011  2:58 AM
+
+> I'm not convinced that only language lawyers care about this issue.
+
+that's NOT what I said,
+
+I said that only language lawyers care about what the Ada standard has to say
+about this issue.
+
+That's a *totally* different point!
+
+In practice, I think the behavior of compilers is going to be driven far more by
+what users/customers need/expect than verbiage in standards, and for sure the
+verbiage in the Ada standard is not going to have any influence.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, January 13, 2011  3:04 AM
+
+I actually am all in favor of trying to define volatile (in all languages) more
+clearly, I just don't see much point in spending much time trying to come up
+with Ada's idiosyncratic viewpoint on this subject.
+
+The problem is basically the same in all these languages, so it is something
+that should be addressed in a more global way than just working on an individual
+standard.
+
+Is there an ISO group more suitable to this work?
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, January 13, 2011  5:29 AM
+
+> In practice, I think the behavior of compilers is going to be driven
+> far more by what users/customers need/expect than verbiage in
+> standards, and for sure the verbiage in the Ada standard is not going
+> to have any influence.
+
+Perhaps, though I have been surprised at the number of people who seem to study
+these descriptions of volatile in other standards, so I wouldn't be surprised if
+the words in the Ada standard are also being read by people with influence in
+the embedded-systems community.
+
+****************************************************************
+
+From: Alan Burns
+Date: Thursday, January 13, 2011  6:48 AM
+
+I'll pass back to Santi the essences of these emails.
+
+Basically we are not really making any change to volatile but loosening what is
+said in the AARM and pointing to the need for control over ordering.
+
+Also that evolving C solution is in practice what will be available in Ada. I'll
+not get involved in any Ada-Comment discussions, but if Santi gets back to me
+with anything that I feel should be shared, I'll do just that.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, January 13, 2011  1:19 PM
+
+> Basically we are not really making any change to volatile but
+> loosening what is said in the AARM and pointing to the need for
+> control over ordering.
+
+I posted yesterday a public reply thanking him for his input and pointing this
+out.
+
+> Also that evolving C solution is in practice what will be available in
+> Ada.
+
+I didn't discuss this, because to me the important point is that "Robert Dewar
+says that GNAT will ignore what the Ada standard says in any case and do
+whatever GCC does for Volatile." And that seems pretty dangerous, because I
+don't want to put wording in Robert's mouth or make any representations about
+what AdaCore will do (a company I don't even work for). I'd rather leave that to
+AdaCore.
+
+The C standard is a red herring here (at least presently) because it doesn't
+really say anything. And we cannot reference standards that might happen in the
+future. And defining things without saying what they mean is bogus at best.
+
+I like Robert's idea of getting multiple language groups together to figure out
+what "volatile" should mean, and if that happens Ada's standard surely should
+take advantage of it, but that clearly will be too late for Ada 2012.
+
+> I'll not get involved in any Ada-Comment discussions, but if Santi
+> gets back to me with anything that I feel should be shared, I'll do
+> just that.
+
+I would hope that he posts any observations on Ada-Comment, so that they too get
+in the public record. Every level of indirectness adds misinterpretations to
+people's opinions.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Date: Thursday, January 13, 2011  3:07 PM
+
+> Again, only a language lawyer cares about this issue, to me it is a
+> waste of time. If you try to come up with a "really good correct
+> definition" of volatile
+
+Au contraire. It is THE major concern that gets voiced when manufacturing
+industry worries about the safety of its C-code in the context of shared-memory
+parallelism. They all want to implement wait-free communication via atomic
+accesses to "shared variables" to be guaranteed to work, which to them means
+  - no cacheing of the value in registers or temps by the compiler,
+  - atomic write/read-through to memory or, alternatively, atomicity and
+    guaranteed cache coherency,
+  - no "relevant" instruction swapping around the access
+    (with varying views on "relevant", usually starting at "any") And they want
+    close to zero direct overhead; they usually do not understand the notion of
+    distributed overhead. Implicit mutexes are obviously out.
+
+True, they won't (try to) find the answers in the reference manual.
+They will instead (try to) force the compiler writers to do right by them, "so
+that the existing code works". And right they are if compiler writers ignore
+their standard. It is not gcc that they are trying to force, so gcc is not the
+gold standard in this realm.
+
+As a deja-vu, I see customers who are trying to leverage the language standards
+against compiler writers in lieu of paying for the right implementation. We've
+been there before with Ada.
+
+So, for a language like Ada, it is not good to neglect this concern by saying
+"whatever happens, happens".
+
+Note incidently the contradiction:
+"Look at Java, C and C++ and how hard they try." (Maybe they have a reason!)
+"Therefore Ada can neglect the issue, let the others figure it out." (It is not
+that important.) Ada is a bit special, since its integration of parallelism
+comes with an obligation to make it work "right". (Unlike C, where it is the job
+of the library providers to do the right things, beyond the elementary notion of
+read/write-through or any equivalent implementation, which par force involves
+the compiler and hence usually the language).
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, January 13, 2011  3:56 PM
+
+I still think that if you want to address this issue, you must do it in a
+cross-language setting. An Ada-only solution in the standard will be ignored by
+users and implementors.
+
+Implementors such as us, certainly want to do the right thing, but we will pay
+attention to what users want/need, and of course this will be discussed in the
+language independent context of gcc, since it makes no sense to discuss it just
+for Ada. And users similarly are interested in getting the compiler to behave in
+a reasonable manner, independent of what the standard has to say.
+
+When I say GNAT will pay no attention to what the Ada standard says, it is not
+that I think the issue is unimportant, rather we have to find the useful
+solutions for users in a language independent context in gcc. If we can't
+convince C to do a particular thing, then gcc/Ada won't do it either.
+
+****************************************************************
+
+From: Alan Burns
+Date: Friday, January 14, 2011  2:59 AM
+
+Just for the record, Santi seems to happy with my reply clarifying what we are
+going (or indeed not going)
+
+---
+
+Thanks Alan for your detailed answer, I finally understand the intent of this AI
+(didn't notice that it was just an AARM note). Sorry for the noise.
+
+
+>  first that volatile need not necessarily mean that the ultimate
+> memory location of the variable is updated - this could happened, but
+> it may be sufficient to put the value out to coherent cache.
+
+Agreed
+
+
+>  The second change is to draw attention to the fact that operations on
+> volatile variables should not get reorders - and that appropriate
+> memory barriers be used where necessary.
+
+If "memory barrier" means "compiler memory barrier" directive (i.e. the compiler
+must not move accesses after or before that point) I completely agree.
+
+What would depart from the C / C++ behavior would be to suggest that the
+compiler must insert "hardware memory barrier" instructions for volatile
+accesses, as done in Java.
+
+>  Ada approach is really to follow what is happening to C (&C++) and
+> give the same level of control.
+
+I'm not a C fan... :-)  but in the case of the library of atomic operations I
+think is very good news!
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent