From bobduff  Wed Dec 16 15:55:49 1992
From: bobduff (Bob Duff)
To: ada9x-mrt
To: iso@ajpo.sei.cmu.edu
Subject:  LSN-1059 on Dangling Task Id Checking

!topic LSN on Dangling Task Id Checking
!key LSN-1059 on Dangling Task Id Checking
!reference MS-G.5.2;4.9
!from Bob Duff $Date: 92/12/16 15:49:14 $ $Revision: 1.2 $
!discussion

This Language Study Note discusses the issue of dangling task ids.

At the November ISO/WG9 meeting in Salem, it was agreed that task
identifiers should be of some special type, and that attribute
notation should be used to get the id of a given task.  This left one
open issue, which is whether or not run-time checks should be done to
prevent access through a dangling task id.  It was agreed to "let the
MRT decide."  The purpose of this LSN is to document our decision.
The resolution is number 10-2 of the Salem meeting.

The issue is simple: if a program stores the id of task T, and then T
disappears (it terminates, its master returns, the run-time system
deallocates its storage), then what happens to subsequent references
to that task id.  We consider two choices:

    Erroneous.  In this choice, the official semantics is that the
    reference is erroneous.  Implementations are free to perform
    checks to detect the problem.

    Checking Required.  The intention of this choice is that the
    following implementation of checking should be allowed: A generation
    count is kept for each task and each task id.  When referencing
    through a task id, the generation counts are checked -- an exception
    is raised if there's a mismatch.  This method of checking is not
    necessarily the only one.

We choose the Erroneous choice, for the following reasons:

    1. We have heard many strong arguments from potential Ada 9X users
       on both sides of this issue.  Therefore, we believe it is better
       to let the market decide.  In other words, there is a trade-off
       between safety and efficiency/simplicity.  We cannot make such a
       trade-off correctly in the language design for everyone, since
       different users have different needs.

    2. This is clearly the simplest to implement.  It provides the
       maximum flexibility -- implementations can tailor the provided
       checking to the needs of their customers.

    3. This is clearly the easiest to specify in the RM.  It is
       difficult to formalize the alternative (the Checking Required
       one).  The problem is that the generation counting method can
       fail if the counter wraps around.  If the counter is 32 bits, it
       is unlikely to wrap around, and even if it does, it is highly
       unlikely that a task will happen to get an id that causes the
       problem.  The semantic problem is that it is hard to say "highly
       unlikely" in a formal requirement.  Note that nobody has
       seriously suggested requiring checks to work properly with
       complete certainty.  The "highly unlikely" idea is assumed to be
       good enough.

    4. This is more uniform with the way dangling access values are
       handled.  Since the problem is the same, it makes sense that the
       solution is the same.

    5. We don't really care that much, so we flipped a coin,
       and it came out heads. ;-)

SUMMARY:

Reference through a dangling task id is erroneous.
Implementations can, of course, add run-time checks.
------ Output from automsg.perl ------
Mail received from bobduff
*** Key LSN-1059 given to topic 'LSN on Dangling Task Id Checking'