CVS difference for ai12s/ai12-0267-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0267-1.txt

--- ai12s/ai12-0267-1.txt	2018/06/30 02:07:34	1.4
+++ ai12s/ai12-0267-1.txt	2018/07/15 00:01:46	1.5
@@ -941,4 +941,307 @@
 other writing. I want to put the work into allowing cases of reading that can't
 naturally be allowed (like cursor operations in the containers).
 
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, June 30, 2018  12:57 AM
+
+>      procedure Write is   -- Globals out: A 	
+>                           -- Globals in: B
+>                           -- Globals in out: Ready
+>       begin
+>          while Ready loop null; end loop;
+>          A := 42 + B;
+>          Ready := False;
+:= True, I guess
+>       end Write;
+>
+>       procedure Read is  -- with Globals out: B
+>                          -- Globals in: A
+>                          -- Globals in out: Ready
+>       begin
+>          while not Ready loop null; end loop;
+>          B := A - 42;
+>          Ready := True;
+:= False, I guess
+>       end;
+>
+> This code does not have a data race, not even a general race 
+> condition.
+
+Hmmm... as long as you can prove there is only one task calling Read, and one 
+task calling Write
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 30, 2018  1:22 AM
+
+...and the error demonstrates just how hard it is to get these things right.
+And this is only toy code. It's often much harder in real situations.
+
+Yes, these errors will cause some pain. That's not unlike the pain caused by 
+other Ada errors and checks (strong typing; strong hiding; range checks).
+Ada programmers soon learn that the gain is worth the pain. The same is likely
+to be true here - reducing thread communication means code that is more easily
+parallelized automatically as well as manually.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, July 1, 2018  5:46 AM
+
+> In cases like this, A and B should be in a protected object
+
+I could not agree more in theory. However ...
+
+> No one but a true tasking guru can prove that.
+
+No. In more than 10 years of analyzing code that is running in cars, I have 
+not seen a single use of a construct like a semaphore, mutex, and alike. And
+it is not just single programmers, it is an entire application domain that 
+works this way.
+
+The programmers are not gurus and yet our cars work (mostly).
+
+They manage to write the code in such a way that a deadlock is provably 
+impossible, since there are no primitives used that could cause them.
+(The possibility of livelooks is blissfully ignored or dealt with a code 
+review levels.)
+
+The synchronization is done either via flags (as in my example) or, more 
+often, via states in the path predicates (the system cannot be in states
+15 and 31 at the same time) plus appropriate state management.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, July 1, 2018  5:58 AM
+
+>> This code does not have a data race, not even a general race 
+>> condition.
+> Hmmm... as long as you can prove there is only one task calling Read, 
+> and one task calling Write
+
+I stand corrected wrt the comment in the code.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, July 1, 2018  11:12 AM
+
+...
+> Example 2: do the rules prevent legitimate programs?
+> 
+> The following idiom (minus the B, which I added just for fun) to 
+> protect the uses of A gets taught in C++ classes:
+> 
+>   Ready: Boolean := False with Atomic, Volatile;
+>         -- I never remember which one implies the other in Ada
+>   -- A and B of arbitrary type, here Integer
+>   A, B: Integer := 0;
+> 
+>     procedure Write is   -- Globals out: A
+>                          -- Globals in: B
+>                          -- Globals in out: Ready
+>      begin
+>         while Ready loop null; end loop;
+>         A := 42 + B;
+>         Ready := False;
+>      end Write;
+> 
+>      procedure Read is  -- with Globals out: B
+>                         -- Globals in: A
+>                         -- Globals in out: Ready
+>      begin
+>         while not Ready loop null; end loop;
+>         B := A - 42;
+>         Ready := True;
+>      end;
+> 
+> This code does not have a data race, not even a general race condition.
+> Illegal in Ada? or legal only, if all ckecks are off ??? Neither will 
+> be good advertising for Ada.
+
+I'm not sure I understand the purpose of this example. It appears that one of 
+these two routines, if called, will exit without changing the state of Ready 
+(but assigning it a confirming value), and the other one is guaranteed to get
+caught in an infinite loop if called.
+
+Or did you intend Write to set Ready to True, and Read to set Ready to False? 
+I suspect this is the case, in which case as Jean-Pierre suggests, this only 
+works for a single reader + single writer scenario. If this is the case, it is
+a case in point (logic bug not easily spotted) for showing better support for
+using safer constructs such as protected objects, as Randy was suggesting.
+
+Or are you suggesting or asking if the rules of the AI should detect this 
+logic problem?
+
+Or am I missing something?
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, July 1, 2018  7:17 PM
+
+> ..and the error demonstrates just how hard it is to get these things right.
+> And this is only toy code. It's often much harder in real situations.
+
+Well, it was not an error. It was an idiom for a one-to-one situation that 
+would indeed not work in a many-to-one/many situation. For many-to-X you 
+normally need CAS and family, or else higher-level constructs.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, July 1, 2018  9:33 PM
+
+Getting the True and False flags reversed is an error! Moral: use protected 
+objects, not "idioms". 
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, July 1, 2018  9:06 PM
+
+> Or did you intend Write to set Ready to True, and Read to set Ready to 
+> False? I suspect this is the case, in which case as Jean-Pierre suggests,
+> this only works for a single reader + single writer scenario.
+
+Yes, indeed. So, I messed up the coding by inverting the two assignments.
+
+But the point remains that code like that (without stupid coding mistakes) 
+does work for the one-to-one purpose intended, and that the automotive 
+community has traditionally not been using higher level constructs. Ramming
+them down their throat will not help. We need to allow such code without 
+poo-pooing it.
+
+That was the purpose of the example.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, July 1, 2018  9:46 PM
+
+But are these sorts of organizations really customers for Ada? You can write 
+low-level code (that may or may not work) in any language -- the benefits of 
+Ada aren't really available for such code in any case. To get the benefits of
+Ada, one has to write higher-level code in a different style than they're 
+accustomed. Is there any benefit to advertising that Ada is no more safe than
+any other language?
+
+If some organization wants to write unchecked Ada code, they can by setting 
+the policy appropriately. They won't get any benefit from using Ada this way,
+but perhaps they'll find some benefit in other existing parts of Ada.
+For the rest of us, that aren't capable of correctly writing tasking 
+communication using idioms (which apparently includes you :-), there is a 
+default safe mode. Seems like a win-win to me. (And maybe the "automotive 
+community" will learn something about structuring multi-threaded code. But I'm
+skeptical.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, July 2, 2018  2:39 PM
+
+I have lost the thread here, I fear, but I believe it is important that Ada 
+provide low-level coding primitives, including unsafe ones (at least under 
+some kind of "Unchecked" banner), because it is much more painful to be forced
+to write such low-level stuff in some other language (e.g. C) when most of the
+system is written in Ada, because you then end up having to worry about 
+multiple compilers, potentially incompatible calling conventions, etc.  Ada 
+certainly has better-than-average "import" and "export" capabilities, but 
+having to get multiple compilers working smoothly together, potentially across
+multiple targets, with your build system and run-time libraries, can be a real
+pain, and they will often be upgraded on different schedules, etc. 
+
+Clearly smart users will minimize and isolate their use of low-level coding, 
+which is simpler in Ada due to its good modularization and information hiding,
+but we shoot ourselves in the foot if we get too insistent that all portable 
+Ada code must be completely safe and high level.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, July 3, 2018  6:23 AM
+
+Exactly my point and view.
+
+My mails are/were about the possible consequence:
+"If you want your "unsafe" program compiled, you must delete the Global specs, 
+or repent and use the "safe" concepts instead."
+
+I believe we resolved this in Lisbon in principle by adding a "do not check 
+race conds based on Global specs"-option. (The examples were written prior to
+that resolution.)
+
+****************************************************************
+
+From: Peter Chapin
+Sent: Tuesday, July 3, 2018  12:06 PM
+
+i don't have any experience in the automotive industry, but i have to say that 
+it disturbs me a little to learn that automotive software developers routinely 
+use such low level methods to manage multi-tasking!
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Saturday, July 7, 2018  4:15 PM
+
+Some minor comments that I didn’t raise at the meeting as the AI was going 
+back for a re-write anyway...
+
+!proposal
+
+Missing new-lines before the first two goals.
+
+!wording
+
+There is some over-zealous changing singular to plural:
+
+Modify 5.5.2(7/5) last two sentences
+
+The loop parameters may be plural but the subtype is still singular.
+
+Modify AARM 5.5.2(8.a/5) last sentence
+
+The loop parameters may be plural but the accessibility is still singular.
+
+Modify 5.5.2(8/3) first and last sentences
+
+I would prefer to change “constant” to a plural to keep the word as a noun 
+rather than changing to using it as an adjective.
+
+Modify A.18.2(230.2/3)
+
+Modify A.18.2(230.4/3)
+
+Modify A.18.3(144.2/3)
+
+Modify A.18.3(144.4/3)
+
+Modify A.18.6(61.2/3)
+
+Modify A.18.6(94.2/3)
+
+Modify A.18.6(94.4/3)
+
+Modify A.18.8(85.2/3)
+
+Modify A.18.9(113.2/3)
+
+Modify A.18.9(113.4/3)
+
+Modify A.18.10(157/4)
+
+Modify A.18.10(159/4)
+
+I would prefer to change “a loop parameter” to “the loop parameters” rather 
+than “loop parameters”.
+
+!discussion
+
+2nd para – capitalise the first letter.
+
 ***************************************************************

Questions? Ask the ACAA Technical Agent