Re: How to avoid unreferenced objects (mutexes etc)

[Darren New <dnew@san.rr.com>]

Matthew Heaney wrote:
> 
> "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).

Sure. Now Op can't act as an entry.

The basic problem is that if I have something that says 
  x.boop
and boop is an entry, it can only call one specific piece of code. That
one specific piece of code has to be the one that determines whether the
code blocks.


> > 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?

That's not guarding an entry. If T.op dispatches, then it can't be an
entry. If it's an entry, I can't override it.

I can't do
  select T.op or delay 10.0 ; yadda end select;
and have T.op be one of two different pieces of code, for example.

The problem I had was trying to build a library wherein the framework
instantiates a number of tasks. Each task is provided by the user of the
framework. (Think, for example, of someone writing multiple types of
windows in a GUI framework.) Each task would need to respond to
different events at different times (meaning selective accepts in the
tasks) and the framework wanted to not have to know what all these
different task types are (meaning dispatching). Couldn't figure out how
to do it properly. Wound up building a kludge that basically involved
manually marshalling all the messages and queueing them, and generally
reimplementing the entry queue mechanism in Ada.

> I haven't found a need for extensible tasks.

I have, but then that's the kind of software I write.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  The opposite of always is sometimes.
   The opposite of never is sometimes.