comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Subject: Re: Delayed deallocation of non-terminated task in Gnat?
Date: Wed, 31 Aug 2011 16:58:06 -0400
Date: 2011-08-31T16:58:06-04:00	[thread overview]
Message-ID: <wccr541cn8h.fsf@shell01.TheWorld.com> (raw)
In-Reply-To: 1upog8dc7hzkz$.wy4yj6fhgo40$.dlg@40tude.net

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Yes. If there exist terminate alternative, it must have a corresponding
> entry. E.g.
>
>    T'Terminate
>
> could denote the terminate entry of the task T. The semantics of the
> rendezvous to T'Terminate is obvious, upon completion the callee is
> terminated. It would be simple to introduce, IMO.

Simple to introduce from a semantics point of view, and useful,
but rather tricky to implement, for the same reasons that the
feature we're discussing (avoiding the storage leak) is tricky.
If a task itself notices that it is about to terminate,
and therefore frees resources (the task control block,
the task stack), it is running while it's doing that stuff,
and it's tricky to make sure it doesn't use those resources
after they're freed.  E.g., the free wanted to defer/undefer
aborts, which involves touching the task control block,
which is being freed!  We figured out how to do it, and it
wasn't a lot of code, but it was very subtle code.

>> or a group of tasks.
>
> There is no rendezvous to multiple tasks or calls to multiple entry points
> (of several protected objects).

That was proposed for Ada 9X.

>... It could be useful but the semantics is
> unclear.

As I recall, there was both "and" and "or" semantics.  So in the context
of termination, that would give you "wait until all these tasks are
terminated", and "wait until one of these tasks is terminated (and tell
me which one)".

>> I'm not sure U_D should be that feature, though,
>> because then it would only work for access-to-task(s).
>
> It certainly should. The behavior of an object may not depend on the way it
> was allocated. Since deallocation of a task on the stack is effectively
> blocking, so its deallocation using Unchecked_Deallocation should be. I see
> no use in a non-blocking Unchecked_Deallocation.

Maybe you're right, I'm not sure.  I think it does make sense to fire up
a task, and have it get freed on termination, with no particular other
task waiting for that termination.  The U_D you want, that waits for
termination, can be written in terms of the mythical "await termination"
primitive we discussed above, and the existing Ada U_D that does not
wait.

- Bob



  reply	other threads:[~2011-08-31 20:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-30 13:22 Delayed deallocation of non-terminated task in Gnat? Marc C
2011-08-30 15:20 ` Dmitry A. Kazakov
2011-08-31 18:12   ` Robert A Duff
2011-08-31 19:23     ` Dmitry A. Kazakov
2011-08-31 20:58       ` Robert A Duff [this message]
2011-08-31 21:16         ` Jeffrey Carter
2011-08-31 20:25     ` J-P. Rosen
2011-08-31 21:09       ` Robert A Duff
2011-08-31 21:53         ` Simon Wright
2011-08-30 15:38 ` Adam Beneschan
2011-08-30 16:42   ` Dmitry A. Kazakov
2011-08-30 18:57     ` Niklas Holsti
2011-08-30 19:23       ` Dmitry A. Kazakov
2011-08-31 16:39   ` Adam Beneschan
2011-08-31 18:21     ` Robert A Duff
2011-08-31 23:28       ` Adam Beneschan
2011-09-01 11:58         ` Robert A Duff
2011-08-31 20:30     ` J-P. Rosen
2011-08-31 22:36       ` Adam Beneschan
2011-09-01  5:24         ` J-P. Rosen
2011-08-31 18:08 ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox