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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6009c73a58f787a0
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-01-15 10:52:32 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Matthew Heaney" <mheaney@on2.com>
Newsgroups: comp.lang.ada
Subject: Re: How to avoid unreferenced objects (mutexes etc)
Date: Tue, 15 Jan 2002 13:57:08 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <u48ujffufrl77b@corp.supernews.com>
References: <3c3ee8c8.105408250@News.CIS.DFN.DE>
 <a1o2h1$sfe3f$5@ID-25716.news.dfncis.de> <3c429d1c.2624281@News.CIS.DFN.DE>
 <u48j5j2gh9lse8@corp.supernews.com> <3C445F34.44697AEF@san.rr.com>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Complaints-To: newsabuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:18942
Date: 2002-01-15T13:57:08-05:00
List-Id: <comp.lang.ada>


"Darren New" <dnew@san.rr.com> wrote in message
news:3C445F34.44697AEF@san.rr.com...
> Matthew Heaney wrote:
> > Now  you're free to derive types from T, and bind derived type instances
to
> > a task.  Using this idiom obviates the need for extensible task types.
>
> Not really, because there are various operations that may only be
> applied to entries, and various operations that may only appear in task
> bodies and hence your T and its derived types cannot affect it.

But won't this work:

package P is
   type T is abstract tagged limited private;
   procedure Op (O : in out T) is abstract;
private
   task type T_Task_Type (O : access T) is
      entry E;
   end T_Task_Type;

   type T is abstract tagged limited record
      T_Task : T_Task_Type (T'Access);
   end record;

end P;

Now each instance of T gets its own thread.  Types in T'Class have
visibility to the task object (assuming they are declared in children of P).


> As an example, if your task is coded without any guards on the entries,
> there's no way for a child of T to add a guard.

But couldn't a derived type NT extend T to include a protected object (that
implements a semaphore, say), that could be used by types in NT'Class to do
the same thing?


> You can do a fair amount with this idiom, but I wouldn't say it
> *obviates* the need for extensible tasks.

I haven't found a need for extensible tasks.