Re: How to avoid unreferenced objects (mutexes etc)

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

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3c429d1c.2624281@News.CIS.DFN.DE...
> Absolutely. So my suspicion goes. Or else, there must be something
> fundamentally wrong [in design] if unused objects are *really*
> required. It clearly indicates a *problem*.

The problem is that the language doesn't have a termination handler for
blocks, a la a "finally" clause in Java or Win32 Structured Exception
Handling.  So you have to create "unused" objects as a work-around.


> A "natural" solution would be to extend monitors, but alas tasks
> are not tagged.

Can't you parameterize a task with an access discriminant that binds to an
object whose type is class-wide, and then call (dispatching) operations on
that object?

type T is tagged limited null record;
procedure Op (O : access T);

task Task_Object (O : access T'Class) is ..

task body Task_Object is
begin
  ...
  Op (O);  --dispatching call to object viewed thru access discrim
  ...
end;

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.


> So I chose the lesser evil = mutexes with all that nasty problems of
> error recovery, you have pointed. I really do not like it.

The language gives you primitives so that you can use to build in the
safety.  There is no problem using semaphores in Ada95, if you follow
certain idioms.