Bryan@SIERRA.STANFORD.EDU (Doug Bryan) (07/12/87)
Dear Ada Fans,
After a long summer break, we're back with our pain-in-the-rear
questions. We have a nasty one about the semantics (or lack thereof)
of RM 9.10(7). Consider the following:
with Text_Io;
procedure Main is
type Text is access String;
task A;
task B is
entry E (T : Text);
end B;
T : Text := new String'("xxxx");
task body A is
begin
B.E (T);
exception
when Tasking_Error => Text_Io.Put_Line (T.all & T.all);
end A;
task body B is
begin
accept E (T : Text) do
T.all := "yyyy";
end E;
end B;
begin
abort B;
end Main;
Is it possible for this program to print:
xxxxyyyy
The following scenario seems possible (assuming a single
CPU system simplifies life):
1. the rendezvous begins
2. task B becomes abnormal (but not completed)
3. Tasking_Error is raised in task A
4. task A handles the exception
5. the left-hand operand of "&" is evaluated (yielding "xxxx")
6. task B executes the assignment statement
7. the right-hand operand of "&" is evaluated (yielding "yyyy")
8. the Put_Line takes place
The wording in 9.10(7) seems not to preclude an abnormal task engaged
in a rendezvous from continuing execution AFTER the caller has received
and/or handled Tasking_Error. If this is possible, then the called task
can still be mucking with actual parameters, while the calling task has
continued its own execution.
If this is possible, we'll never use Ada again! 'C' doesn't have this
problem!! :-)
Bonus Question: What does 9.10(8) have to do with the price of eggs?
We don't understand how this could happen.
doug and geoff
-------keith@telesoft.UUCP (Keith Shillington @prodigal) (07/14/87)
The situation you describe with respect to 9.10(7) is impossible. A cannot possibly resume execution be it via TASKING_ERROR or normal circumstances until B completes the rendezvous. The last sentence in 9.10(6) warrants the completion of the rendezvous. 11.5(5) and 9.5(14) warrant the order of execution. 9.10(8) [Bonus Answer] Refers, at least, to situations such as an exception being raised in the process of the assignment; consider, for example, the situation where a CONSTRAINT_ERROR is raised in evaluating the right hand side of an expression. The task becomes abnormal, and the value of the variable is undefined. Keith Allan Shillington telesoft!keith@UCSD.ARPA ...!sdcsvax!telesoft!keith.UUCP 619/457-2700x388.ATT
stt@ada-uts (07/14/87)
Although I agree it is not specific here, it would not be meaningful for a rendezvous to continue after the caller receives TASKING_ERROR and begins to process it. A rendezvous by definition occupies the full attentions of both tasks. To be clear, it should probably say that TASKING_ERROR is raised no sooner than the completion of the rendezvous, and no later than the abnormal completion of the aborted task. As far as 9.10:8 -- Imagine a variable which is a large record being updated by record assignment. If a task is aborted and becomes completed in the middle of the assignment, then the value of the variable may be unmeaningful, with the record only partially updated, and perhaps even a single component only partially updated. In this sense, the value is formally "undefined," which means that it is erroneous to use or rely on the value. Similar wording appears in 3.2.1:17/18, where it states that "The execution of a program is erroneous if it attempts to evaluate a scalar variable with an undefined value. Similarly, the execution of a program is erroneous if it attempts to apply a predefined operator to a variable that has a scalar subcomponent with an undefined value." S. Tucker Taft c/o Intermetrics, Inc. Cambridge, MA 02138