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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,b4731a3b5d591abd
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Task Discriminants & Arrays
Date: 1997/05/13
Message-ID: <EA4L3s.B26@world.std.com>#1/1
X-Deja-AN: 241290655
References: <mheaney-ya023680001305970024550001@news.ni.net>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-05-13T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <mheaney-ya023680001305970024550001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>It would be really swell if I could give the task object component of the
>array an identifier that is its index position in the array.  Anyone got
>any ideas about how to do this?

You can give the discriminant a default, which is a function that
increments a counter and returns the new value.  (Horrors!  A function
with a side-effect! ;-))  This will not guarantee that A(I).Id = I,
since the array components are initialized in an arbitrary order.  But
it does guarantee that each task will get a unique Id, which might be
what you want.  Note that the initialization happens before the tasks
are activated, so there's no need to protect the counter from evil
parallel access.

If you really insist that each task's Id be its index, then make it an
array of *pointers* to tasks, and write a loop:

    for I in A'Range loop
        A(I) := new T(Id => I);
    end loop;

Note that this has a slightly different effect -- the tasks are
activated one at a time, rather than in parallel.  So you will probably
want to move any substantial initialization code that appears in the
task's declarative part, down into a block statement.  In your
array-of-tasks example, the activations happen in parallel.  And the
parent task always waits until the activatee's finish executing their
declarative parts.

By the way, if tasks are represented internally as pointers to task
control blocks (could be addresses, or indexes into a table of TCB's),
which is common (in fact, it was pretty much *required*, in Ada 83),
then a compiler can optimize by representing "access T" in the same way
as plain "T".  That is, it is *not* necessary to represent "access T"
with a double indirection -- as a pointer-to-a-pointer-to-a-TCB.  This
is because "=" is not defined on tasks.  I don't know if any compilers
do this optimization -- it's probably not worth the trouble.  I only
mention it because I think it's kind of "neat".

- Bob