* Missing accept statement
@ 1990-03-15 20:35 westley
1990-03-16 3:25 ` Karl A. Nyberg
1990-03-16 14:34 ` arny.b.engelson
0 siblings, 2 replies; 6+ messages in thread
From: westley @ 1990-03-15 20:35 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Missing accept statement
1990-03-15 20:35 Missing accept statement westley
@ 1990-03-16 3:25 ` Karl A. Nyberg
1990-03-16 14:34 ` arny.b.engelson
1 sibling, 0 replies; 6+ messages in thread
From: Karl A. Nyberg @ 1990-03-16 3:25 UTC (permalink / raw)
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 --
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Missing accept statement
1990-03-15 20:35 Missing accept statement westley
1990-03-16 3:25 ` Karl A. Nyberg
@ 1990-03-16 14:34 ` arny.b.engelson
1990-03-17 6:01 ` Barry Margolin
1990-03-19 18:29 ` Terry J. Westley
1 sibling, 2 replies; 6+ messages in thread
From: arny.b.engelson @ 1990-03-16 14:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Missing accept statement
1990-03-16 14:34 ` arny.b.engelson
@ 1990-03-17 6:01 ` Barry Margolin
1990-03-19 18:29 ` Terry J. Westley
1 sibling, 0 replies; 6+ messages in thread
From: Barry Margolin @ 1990-03-17 6:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Missing accept statement
1990-03-16 14:34 ` arny.b.engelson
1990-03-17 6:01 ` Barry Margolin
@ 1990-03-19 18:29 ` Terry J. Westley
1 sibling, 0 replies; 6+ messages in thread
From: Terry J. Westley @ 1990-03-19 18:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <203521@<1990Mar15>]
end of thread, other threads:[~1990-03-19 18:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1990-03-15 20:35 Missing accept statement westley
1990-03-16 3:25 ` Karl A. Nyberg
1990-03-16 14:34 ` arny.b.engelson
1990-03-17 6:01 ` Barry Margolin
1990-03-19 18:29 ` Terry J. Westley
[not found] <203521@<1990Mar15>
1990-03-16 16:52 ` stt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox