Re: Erroneous execution? (was Re: gnat: time-slicing)

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Ben Brosgol" <brosgol@world.std.com> 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