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-13 15:31:24 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Erroneous execution? (was Re: gnat: time-slicing) Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Tue, 13 Aug 2002 22:30:52 GMT References: NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:27990 Date: 2002-08-13T22:30:52+00:00 List-Id: "Ben Brosgol" writes: > > 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). It seems to me that Put_Line(X) ought to have *exactly* the same semantics as Put_Line(Current_Output, X). So if one is erroneous (when executed simultaneously by two different tasks) then so should the other. I must admit that the RM wording is not crystal clear on this point. Besides, if it's not erroneous, I see no particular reason why the required locking would be at the character level. Why not at the level of individual calls like Put_Line? Why can two simultaneous Put_Lines intersperse the characters, but not the bits? Why shouldn't they be required to intersperse lines? > 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 sin(x) example seems different. Surely two simultaneous calls to sin should be OK, since sin is a mathematical function. If it has internal (implementation-level) side-effects, then the implementation should hide them. But Put_Line is different -- it is *supposed* to have a side effect, namely, it is supposed to write upon the Current_Output file. (In fact, it seems silly to call that a "side effect"; it's really just the "effect" (no "side" about it).) > Well of course the AARM has no formal status :-) True (and I see the smiley). But the AARM indicates (often more clearly than the RM) what the language designers intended. Language lawyers who ignore the AARM do so at their peril. >...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 :-) OK, I admit it's not clear. > > 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. Yeah, and I think *I* wrote A(3.a). I could be misremembering that, though. I think I meant all the Put procedures when I said "Put". - Bob