From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cuae2!ltuxa!we53!sw013b!dj3b1!killer!ndmce!pollux!infotel!ut-ngp!ut-sally!seismo!think!nike!ucbcad!ucbvax!telesoft.UUCP!gary
From: gary@telesoft.UUCP@ndmce.uucp (Gary Dismukes @lizard)
Newsgroups: net.lang.ada
Subject: Re: Need to see certain data inside a task type.
Message-ID: <326@ndmce.uucp>
Date: Fri, 17-Oct-86 17:06:06 EDT
Article-I.D.: ndmce.326
Posted: Fri Oct 17 17:06:06 1986
Date-Received: Tue, 21-Oct-86 05:24:29 EDT
Sender: news@ndmce.uucp
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


In response to Len Armstrong's question regarding tasks and discriminants:


Since the access that a task has to data outside of its body is essentially
limited to visible objects declared prior to the task body and to data passed
in as entry parameters, there is no way for a task to directly access a
discriminant of a record type containing the task as a component.  At one
point during the language design process there was some discussion of allowing
discriminants to be declared for task types.  However, this was not long before
the standardization of Ada and it was felt that not enough time was available
to give the necessary attention to integrating such a feature so it was not
added.  There is, however, a way to achieve the basic functionality that you
are looking for.  One approach to solving the problem would be to require an
explicit call to an initialization entry after the declaration of the record
object.  Using the given example we would have:

  declare
    X: TR( SOME_VALUE_OF_SOME_TYPE );
  begin
    X.TASK_FIELD.INITIALIZE( X.PARAM_FIELD );
    ...
  end;

This is clearly undesirable because of the separation of the declaration
and initialization of the object.  We would prefer that the user of the
type TR need not be concerned with the initialization of the task.

An alternative approach is to introduce an access type and initialization
function as shown below:


  package PKG is
  
    task type T is
       entry INITIALIZE ( INIT_PARAM: SOME_TYPE );
       entry E1;
       entry E2;
    end T;
   
    type T_ACCESS is access T;
   
    function T_INIT ( INIT_PARAM: SOME_TYPE ) return T_ACCESS;
   
    type TR ( PARAM_FIELD: SOME_TYPE ) is
      record
        TASK_FIELD : T_ACCESS := T_INIT( PARAM_FIELD );
      end record;
   
  end PKG;

  package body PKG is
   
    task body T is
      PARAMETER: SOME_TYPE;
    begin
      accept INITIALIZE ( INIT_PARAM: SOME_TYPE ) do
        PARAMETER:= INIT_PARAM;
      end INITIALIZE;
        ...
    end T;

    function T_INIT ( INIT_PARAM: SOME_TYPE ) return T_ACCESS is
      NEW_T: T_ACCESS := new T;
    begin
      NEW_T.INITIALIZE( INIT_PARAM );
      return NEW_T;
    end T_INIT;

  end PKG;


It then suffices to declare an object of type PKG.TR with the appropriate
discriminant constraint:
  
    XX : PKG.TR( SOME_VALUE_OF_SOME_TYPE );

This solution encapsulates the creation and initialization of the task object
within a function and relies on the ability to use a discriminant in the
default value expression for a record component.  The replacement of the
task component with an access component is largely transparent to the user
because of the implicit dereferencing for entry calls (e.g., XX.TASK_FIELD.E1).
The main disadvantage is that, if deallocation of the task object is an
important concern, an explicit unchecked deallocation will be necessary
unless the implementation supports garbage collection.

There is also a fundamental limitation in using discriminants to parameterize
tasks because the type of a discriminant is restricted by the language to being
a discrete type, but this may not matter for the application considered.


  Gary Dismukes
  TeleSoft