From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63360011f8addace X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-01 21:05:00 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!world!news From: "Ben Brosgol" Subject: Re: Erroneous execution? (was Re: gnat: time-slicing) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: X-Priority: 3 Date: Fri, 2 Aug 2002 03:59:25 GMT X-Msmail-Priority: Normal References: NNTP-Posting-Host: ppp0c015.std.com Organization: The World @ Software Tool & Die X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:27596 Date: 2002-08-02T03:59:25+00:00 List-Id: > > > > with Ada.Text_IO; use Ada.Text_IO; > > > > > > > > procedure Task_Demo is > > > > task A; > > > > task body A is > > > > begin > > > > Put_Line("b"); > > > > Put_Line("b"); > > > > end A; > > > > begin > > > > Put_Line("a"); > > > > Put_Line("a"); > > > > end Task_Demo; > > > > --------------- > > > > > > The above example is erroneous, which means that the output is totally > > > unpredictable. The reason it's erroneous is that two tasks are messing > > > with the same shared variable (the standard output file) at the same > > > time. > > > > Bob- > > > > Are you sure this is erroneous? > > No... > > You're trying to language-lawyer me to death, Ben. ;-) Not quite that extreme, but at least to the point of moderate pain and suffering :-) > I *think* it's erroneous, and I'm sure it was *intended* to be erroneous > by the language designers. I'm not so sure that it was intended to be erroneous. If each task were invoking Put_Line(Some_File, ...) on the same explicitly-passed file parameter, then yes I agree that the execution would be erroneous. But where the shared variable is hidden (i.e., not passed as a parameter), I believe that the implementation needs to provide the protection (for subprograms from predefined packages). As an example of this principle, suppose that the implementor of Ada.Numerics.Elementary_Functions decided to keep a hash table of (arg, sin(arg)) pairs in the package body; i.e., sin(arg) does a hash table lookup and possible insertion. There's no way that the user would know this, so if the implementation did not protect the shared hash table from simultaneous access, calling sin(x) from concurrent tasks could result in erroneous execution. So A(3) kicks in and requires the protection to be supplied. I think the same principle applies to the Put(Char), although in this case it may be a bit more obvious that there's a shared variable lurking in the shadows. > >...The "shared variable" is hidden in the > > private part or body of a predefined library package and ARM paragraph A(3) > > says that in such cases it is the responsibility of the implementation to > > protect the shared variable from getting trashed (*). Now Put_Line is > > equivalent to looping over Put() and then doing a New_Line so the user may > > see interspersed output -- e.g., either or both "b"s might not be > > immediately followed by a newline -- but the implementation would be > > nonconformant with the ARM if, for example, simultaneous calls on Put caused > > the machine to reboot (which was the effect one saw in an early version of > > the old Alsys DOS Ada compiler :-) > > But the AARM annotation attached to this paragraph says: > > 3.a Ramification: For example, simultaneous calls to Text_IO.Put will > work properly, so long as they are going to two different files. On > the other hand, simultaneous output to the same file constitutes > erroneous use of shared variables. Well of course the AARM has no formal status :-) Also, the wording in 3.a is ambiguous, since it might be referring to the Put procedure that has a File_Type as an explicit parameter, in which case I agree that the simultaneous calls are erroneous. > which indicates the intent pretty clearly. Or maybe not so clearly :-) > The program above is doing > output to the same file simultaneously. Agreed, but I still think there's a difference (in the obligation of the implementation to protect against simultaneous access) based on whether the file is passed as an explicit parameter or is hidden in the implementation. > If you want RM exegesis, I'll point you to A.10.6(2), which says the > above is equivalent to passing the current output file as a parameter, > which is clearly a shared variable. A.10.6.2 says: "All procedures Get and Put have forms with a file parameter, written first. Where this parameter is omitted, the appropriate (input or output) current default file is understood to be specified." This is not quite the same as saying that the current default file is understood to be passed as a parameter. I.e., "specified" could be interpreted as "the file that is operated upon by the procedure". > > I'm not recommending that anyone actually write code such as Task_Demo, but > > I don't think it's an example of erroneous execution. > > > > (*) The rule actually says "The implementation shall ensure that each > > language defined subprogram is reentrant in the sense that concurrent calls > > on the same subprogram perform as specified, so long as all parameters that > > could be passed by reference denote nonoverlapping objects." But I believe > > the intent is as I indicated. > > > > -Ben > > P.S. *You* wrote much of Annex A! True, which is why I raised this issue in the first place :-) although if you do not have a similar recollection then maybe what I am remembering (the non-erroneousness of simultaneous calls on Put(Char)) is an intermediate decision that was later changed? In any event I will not claim the credit / blame for the wording of A(3); that was from the pen of Chairman Tuck. -Ben