Re: How to avoid unreferenced objects (mutexes etc)

["Matthew Heaney" <mheaney@on2.com>]

"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.