westley@hercules.uucp (03/16/90)
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@herculeskarl@grebyn.com (Karl A. Nyberg) (03/16/90)
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 --
arny@cbnewsl.ATT.COM (arny.b.engelson) (03/16/90)
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
stt@inmet.inmet.com (03/17/90)
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
barmar@think.com (Barry Margolin) (03/17/90)
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
westley@corsair.uucp (Terry J. Westley) (03/20/90)
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