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

["Ben Brosgol" <brosgol@world.std.com>]

> > > > 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