Re: Missing accept statement

Re: Missing accept statement

[stt]

It is legal to have a task with an entry
with no matching accept body.  It would be friendly for a compiler
to produce a warning for this situation when encountered,
but there is no language requirement to that effect.
Perhaps there should be...

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Missing accept statement

[westley]

The following program compiled and ran successfully on a Sun 4 with the
Verdix 6.0(g) Ada compiler.  There were no compilation errors, no
exceptions, and "A_Task" was put.

with Text_IO;

procedure Missing_Task_Entry is

   task A_Task is
      entry Missing_Entry;
   end A_Task;

   task body A_Task is
   begin -- A_Task
      Text_IO.Put_Line ("A_Task");
   end A_Task;

begin -- Missing_Task_Entry
   null;
end Missing_Task_Entry;

Is it valid for a task body to be lacking an accept statement for a
corresponding entry from the specification of that task?  I can't find a
specific rule in the RM, but this seems contrary to idea of the compiler
catching this class of potential bugs.

Terry J. Westley
Arvin/Calspan Advanced Technology Center
P.O. Box 400, Buffalo, NY 14225
acsu.buffalo.edu!planck!westley@hercules

Missing accept statement

[Karl A. Nyberg]

In article <1990Mar15.203521.28171@planck.uucp> westley@hercules.uucp () writes:

>Is it valid for a task body to be lacking an accept statement for a
>corresponding entry from the specification of that task?  I can't find a
>specific rule in the RM, but this seems contrary to idea of the compiler
>catching this class of potential bugs.

ISO ARG AI-00373/00-co-RE (derived from a comment submitted on 85-08-04) reads:

	It has come to my attention that at least one validated compiler
	does not require that there be in a task body at least one occurence
	of an accept statement (possibly within a selective wait) that
	corresponds to each entry or entry family in the task specification. 

	After reviewing LRM 9, I conclude that there is no requirement that
	every entry have a corresponding accept.  The only statement that
	seems to come close is in 9.5(1): ``The actions to be performed when
	an entry is called are specified by corresponding accept
	statements.'' This might lead one to expect that there will be
	corresponding accept statements, but it hardly seems to state a
	requirement. 

	Moreover, the entire semantics in 9.5 is stated in terms of what
	happens when both an entry has been called and a corresponding
	accept is reached. It follows that when there is no accept, any such
	entry call will simply wait indefinitely.  No semantic difficultly
	results.  (Obviously, even a textual occurence of an accept does not
	assure that it will ever be reached or ever be open when reached.)

	Is it intended that entries need not have a corresponding accept
	statement, or is this an oversight?  (Or is such a requirement
	stated or implied in some less obvious place in the RM?)

RE status commentaries are: "A comment has been received that is not
relevant to an existing commentary, so a new commentray is created together
witha provisional classification of the point addressed by the comment.  co
class commentaries are defined as "The point raised by the commentary can be
resolved by direct reference to the Standard; the point is not considered to
be of general interest."

That this commentary has languished in the ARG these past 4 plus years seems
to me sufficient indication that it is an accepted position.

-- Karl --

Re: Missing accept statement

[arny.b.engelson]

In article <1990Mar15.203521.28171@planck.uucp> westley@hercules.uucp () writes:
[the following program runs flawlessly on Sun4 under Verdix]
>with Text_IO;
>procedure Missing_Task_Entry is
>   task A_Task is
>      entry Missing_Entry;
>   end A_Task;
>   task body A_Task is
>   begin -- A_Task
>      Text_IO.Put_Line ("A_Task");
>   end A_Task;
>begin -- Missing_Task_Entry
>   null;
>end Missing_Task_Entry;

>Is it valid for a task body to be lacking an accept statement for a
>corresponding entry from the specification of that task?  I can't find a
>specific rule in the RM, but this seems contrary to idea of the compiler
>catching this class of potential bugs.

>Terry J. Westley


I could not find anything in the ARM (or the commentaries) that says a task
MUST have an accept statement for every one of its declared entries, just
that there may be more than one.  At a minimum, the ARM should be clarified
on this point.  Assuming that this situation is therefore allowed, I would
hope a compiler would at least produce a warning message.  I would expect
any call to the entry to hang (unless it's a conditional/timed entry call).
In the above example, since there are no calls to the entry, the compiler may
have chosen not to bother with a warning message.  Try adding an entry call
and see if the compiler warns you about the impending deadlock.

The real question is "was it the intention of the language designers to
allow tasks to have zero accept statements for an entry?"  Well guys,
was it?  More questions: If so, why?  Is this really a good idea?

Enquiring minds want to know (and would love to see discussion on almost
anything that is not related to the Ada/C/C++/case/switch jihad).  :-)

  -- Arny Engelson   att!wayback!arny

Re: Missing accept statement

[Barry Margolin]

In article <4623@cbnewsl.ATT.COM> arny@cbnewsl.ATT.COM (arny.b.engelson,wh,) writes:
>The real question is "was it the intention of the language designers to
>allow tasks to have zero accept statements for an entry?"  Well guys,
>was it?  More questions: If so, why?  Is this really a good idea?

I certainly can't speak for the language designers, but to me it seems
reasonable to permit this.  During development of a program you may want to
compile and test a program before it's complete.  The incomplete program
may not have all its accept statements written yet.  This is true even if
there are entry calls for the unwritten accepts, since you may be testing
the code paths that avoid these entry calls.

As you said, it would be reasonable for a compiler to warn about this case.
There's no reason for an incomplete program to compile without warning --
this can save you from inadvertently shipping a program that's missing an
important piece.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

Re: Missing accept statement

[Terry J. Westley]

In article <4623@cbnewsl.ATT.COM> arny@cbnewsl.ATT.COM (arny.b.engelson,wh,) writes:
>I could not find anything in the ARM (or the commentaries) that says a task
>MUST have an accept statement for every one of its declared entries, just
>that there may be more than one.  At a minimum, the ARM should be clarified
>on this point.  Assuming that this situation is therefore allowed, I would
>hope a compiler would at least produce a warning message.  I would expect
>any call to the entry to hang (unless it's a conditional/timed entry call).
>In the above example, since there are no calls to the entry, the compiler may
>have chosen not to bother with a warning message.  Try adding an entry call
>and see if the compiler warns you about the impending deadlock.

Yes, I had already tried calling the entry from within the procedure
body.  TASKING_ERROR occurred, presumably because the task terminated
before the rendezvous could occur.  The following mod to prevent
termination gets no warning from the compiler concerning the missing
entry.  But, happily, the run-time detects DEADLOCK.

procedure Missing_Task_Entry is
   task A_Task is
      entry Missing_Entry;
      entry Stop;
   end A_Task;
   task body A_Task is
   begin -- A_Task
      loop
         select
            accept Stop;
      	 or
            terminate;
	 end select;
      end loop;
   end A_Task;
begin -- Missing_Task_Entry
   A_Task.Missing_Entry;
end Missing_Task_Entry;

Detection is really only this implementation, however.  Since posting
the first message concerning this, I have received the January, 1990,
Supplement 1 of the Ada 9X Project Report.  Page 9-110, Revision Request
#0216, addresses this issue.

Terry J. Westley
Arvin/Calspan Advanced Technology Center
P.O. Box 400, Buffalo, NY 14225
acsu.buffalo.edu!planck!hercules!westley