How to wait for task completion

How to wait for task completion

[wiljan]

Is there a simply way to wait until a task has completed in Ada?
I have a pointer to a task type:
      task type tsk;
      type ptsk is access tsk;
      p:ptsk;
At a certain point I want to clean up the resources that the task is
using but this can only be done when the task is completed.
One can do something like:
    while not p.all'terminated loop
        delay 0.01;
    end loop
Another option whould be to define an entry for the task and call that
entry. When the task terminated then the entry will raise a tasking error.

I have the idea that there must be a simpler way to accomplish this.

Wiljan

Re: How to wait for task completion

[Samuel Tardieu]

>>>>> "Wiljan" == wiljan  <W.Derks@nl.cis.philips.com> writes:

Wiljan> Is there a simply way to wait until a task has completed in
Wiljan> Ada?

Assuming you are referring to Ada 95, you may well associate a
protected type with each task which will have two entries: one called
by the task just before it dies, the other one blocking until the
first one is called (and non-blocking if the first entry has
already been called).

  Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org

Re: How to wait for task completion

[David C. Hoos, Sr.]

wiljan <W.Derks@nl.cis.philips.com> wrote in article
<01bba2e8$c45aad90$35208b82@wd>...
> At a certain point I want to clean up the resources that the task is
> using but this can only be done when the task is completed.

If the task can't clean up its own resources, why not provide a subprogram
it can call just before it terminates?
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Re: How to wait for task completion

[wiljan]

Samuel Tardieu <sam@ada.eu.org> wrote in article
<qw6k9tw3sci.fsf@gargantua.enst.fr>...
> >>>>> "Wiljan" == wiljan  <W.Derks@nl.cis.philips.com> writes:
> 
> Wiljan> Is there a simply way to wait until a task has completed in
> Wiljan> Ada?
> 
> Assuming you are referring to Ada 95, you may well associate a
> protected type with each task which will have two entries: one called
> by the task just before it dies, the other one blocking until the
> first one is called (and non-blocking if the first entry has
> already been called).
> 
In my case I want to wait for task completion, Not until it is almost
completed. The code that has to wait for the task completion want to
clean up resources when that task is terminated. If these resources
are cleaned up before that, it will certainlly lead to erroneous execution.
In my case I want to clean up the task object itself by using
ada.unchecked_deallocation.

Wiljan

Re: How to wait for task completion

[Jon S Anthony]

In article <01bba2e8$c45aad90$35208b82@wd> "wiljan" <W.Derks@nl.cis.philips.com> writes:

> Is there a simply way to wait until a task has completed in Ada?
> I have a pointer to a task type:
>       task type tsk;
>       type ptsk is access tsk;
>       p:ptsk;
> At a certain point I want to clean up the resources that the task is
> using but this can only be done when the task is completed.

Depending on your needs and constraints, the simplest trick would be:

in some code where you require P,
...
    declare
        type Ptsk is access Tsk; -- Put access type here to make block master
        P : Ptsk;
        ...
    begin
        null;
    end;      -- Wait until 

You can also put the block in another "parent" task to avoid blocking
the whole program (if that is desirable and deemed "cheap" enough).

For example:

with Text_IO;
with Objs;  use Objs;
procedure Wait_Ex is
 
    task type Tks;
 
    task body Tks is
    begin
        for I in 1..20 loop
            delay 0.1;
            Text_IO.Put_Line("Hi" & Integer'Image(i));
        end loop;
    end;
 
 
begin
    declare
        type Ptsk is access Tks;
        T : Ptsk := new Tks; 
    begin
        null;
    end;
    Text_IO.Put_Line("Done");
end Wait_Ex;

$ gnatmake wait_ex.adb
$ wait_ex.adb
Hi 1
Hi 2
Hi 3
Hi 4
Hi 5
Hi 6
Hi 7
Hi 8
Hi 9
Hi 10
Hi 11
Hi 12
Hi 13
Hi 14
Hi 15
Hi 16
Hi 17
Hi 18
Hi 19
Hi 20
Done
$
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: How to wait for task completion

[Norman H. Cohen]

In article <qw67mpth8zi.fsf@gargantua.enst.fr>, Samuel Tardieu
<sam@ada.eu.org> writes: 

|> >>>>> "wiljan" == wiljan  <W.Derks@nl.cis.philips.com> writes: 
|>
...
|> wiljan>                                              In my case I want
|> wiljan> to clean up the task object itself by using
|> wiljan> ada.unchecked_deallocation.
|>
|> So you should have a look at the generic package Ada.Task_Attributes: 
|> it lets you attach special attributes onto task running on your
|> system. If you attach an attribute of a controlled type to your task,
|> then it will be destroyed (this the Finalization procedure called)
|> whenever the task is completed.

Indeed, RM95-C.7.2(17) guarantees this.  However, unlike Ada 83, Ada 95
does not guarantee that unchecked deallocation will reclaim the storage
for a task object (or for a composite object with a subcomponent that is
a task object), even if the task has terminated when the deallocation
procedure is called!  See the last sentence of RM95-13.11.2(9).

I hope none of the implementors has read this sentence. :-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: How to wait for task completion

[Ted Dennison]

wiljan wrote:
> 
> In my case I want to wait for task completion, Not until it is almost
> completed. The code that has to wait for the task completion want to
> clean up resources when that task is terminated. If these resources
> are cleaned up before that, it will certainlly lead to erroneous execution.
> In my case I want to clean up the task object itself by using
> ada.unchecked_deallocation.

What I have seen done is creation of a stack of tasks that are currently 
unused. In this particular case each task put ITSELF on the stack when it
was done. Any time a new task was needed, it got pulled off the stack and
re-activated, or created with dynamic allocation if the stack was empty. This
setup could easily be modified to do periodic garbage collection (checking
the 'terminated attribute, just to be safe).

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: How to wait for task completion

[wiljan]

Hello Samuel,

You wrote:

> So you should have a look at the generic package Ada.Task_Attributes:
> it lets you attach special attributes onto task running on your
> system. If you attach an attribute of a controlled type to your task,
> then it will be destroyed (this the Finalization procedure called)
> whenever the task is completed.
I am aware of the existance of this package. Note that I want to be able to
also cleanup the space that the task object itself uses.
Thus when I have a pointer to some task type there is actually some space
allocated for the task itself. I want to free that space also. Normally
that space
is simply allocated with a new.
Note that whatever you do, the task itself can not do that because it is
very dangeraous to do that. After disposal the space might still be
refferenced
by the task itself.
So my question is how to make this program work:
   task type xtask;
   task body xtask is
   begin
       null;
   end xtask;
   type pxtask is access xtask;

   for i in integer'range loop
      declare p:pxtask:=new xtask;
   end loop;
The program can be made working when doing a lot of adminstrating
on the pointers to the objects created in the main program.
I actually want to deallalocate them in the task itself when they complete.

Greetings,

Wiljan

Re: How to wait for task completion

[wiljan]

Norman H. Cohen <ncohen@watson.ibm.com> wrote in article
<51mhns$jif@watnews1.watson.ibm.com>...
> Indeed, RM95-C.7.2(17) guarantees this.  However, unlike Ada 83, Ada 95
> does not guarantee that unchecked deallocation will reclaim the storage
> for a task object (or for a composite object with a subcomponent that is
> a task object), even if the task has terminated when the deallocation
> procedure is called!  See the last sentence of RM95-13.11.2(9).
> 
> I hope none of the implementors has read this sentence. :-)
Incredible. I think here is a point to look at in the next Ada standard.

Thanks for pointing me to the locations in the RM.

Wiljan

Re: How to wait for task completion

[Samuel Tardieu]

>>>>> "wiljan" == wiljan  <W.Derks@nl.cis.philips.com> writes:

wiljan> In my case I want to wait for task completion, Not until it is
wiljan> almost completed. The code that has to wait for the task
wiljan> completion want to clean up resources when that task is
wiljan> terminated. If these resources are cleaned up before that, it
wiljan> will certainlly lead to erroneous execution. In my case I want
wiljan> to clean up the task object itself by using
wiljan> ada.unchecked_deallocation.

So you should have a look at the generic package Ada.Task_Attributes:
it lets you attach special attributes onto task running on your
system. If you attach an attribute of a controlled type to your task,
then it will be destroyed (this the Finalization procedure called)
whenever the task is completed.

  Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org

Re: How to wait for task completion

[Jon S Anthony]

In article <01bba4c7$fa9f4650$2d208b82@wd> "wiljan" <W.Derks@nl.cis.philips.com> writes:

> So my question is how to make this program work:
>    task type xtask;
>    task body xtask is
>    begin
>        null;
>    end xtask;
>    type pxtask is access xtask;
> 
>    for i in integer'range loop
>       declare p:pxtask:=new xtask;
>    end loop;
> The program can be made working when doing a lot of adminstrating
> on the pointers to the objects created in the main program.
> I actually want to deallalocate them in the task itself when they complete.

OK, I don't get it.  There is something about this that is not yet
sufficiently described with respect to what it is you want to achieve.
The above sort of program can be "made to work" by:

    for I in Integer'Range loop
        declare
            P : Xtask;
        begin
            null;
        end;
    end loop;
or
    for I in Integer'Range loop
        declare
            type Pxtask is access Xtask;
            P : Pxtask := new Xtask;
        begin
            null;
        end;
        -- Storage associated with Pxtask is freed.
    end loop;

Since you are not keeping the tasks around after the loop, either of
these will work (though it is hard to see any reason for choosing the
second version).  But, I have the feeling this doesn't really address
what you are after.  So, just what is it you really want?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: How to wait for task completion

[Tucker Taft]

wiljan (W.Derks@nl.cis.philips.com) wrote:
: Norman H. Cohen <ncohen@watson.ibm.com> wrote in article
: <51mhns$jif@watnews1.watson.ibm.com>...
: > Indeed, RM95-C.7.2(17) guarantees this.  However, unlike Ada 83, Ada 95
: > does not guarantee that unchecked deallocation will reclaim the storage
: > for a task object (or for a composite object with a subcomponent that is
: > a task object), even if the task has terminated when the deallocation
: > procedure is called!  See the last sentence of RM95-13.11.2(9).
: > 
: > I hope none of the implementors has read this sentence. :-)

: Incredible. I think here is a point to look at in the next Ada standard.

: Thanks for pointing me to the locations in the RM.

Not surprisingly, there is a bit of history behind this one.
The problem is that Ada 83 claimed that it was OK to free the task
object associated with a task that was still running, and the task
was not supposed to be affected.  We attempted to remain compatible
with this rule, while also allowing more of the critical task information 
(e.g. the Task Control Block) to be held in the task object itself.
These two rules led to task objects requiring special handling with
respect to Free.

In my view, the preferred rule would be that Program_Error is raised if 
you try to free a task object if the task is not yet terminated, but
alas that would not be upward compatible in general.

In fact, we allow Program_Error for tasks with discriminants (RM95 
13.11.3(13)), since there is no upward compatibility issue for such
tasks (Ada 83 tasks couldn't have discriminants).

The warning in 13.11.2(9) should have been replaced with a more carefully
phrased "Implementation Permission."  As it is, it comes out of the blue,
with no explanation, which is admittedly scary.

: Wiljan

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: How to wait for task completion

[Norman H. Cohen]

Tucker Taft wrote:

> The problem is that Ada 83 claimed that it was OK to free the task
> object associated with a task that was still running, and the task
> was not supposed to be affected.  We attempted to remain compatible
> with this rule, while also allowing more of the critical task information
> (e.g. the Task Control Block) to be held in the task object itself.
> These two rules led to task objects requiring special handling with
> respect to Free.
...
> The warning in 13.11.2(9) should have been replaced with a more carefully
> phrased "Implementation Permission."  As it is, it comes out of the blue,
> with no explanation, which is admittedly scary.

Perhaps this justifies implementation permission for attempted
deallocation
of a task object for an ACTIVE task to have no effect (as opposed, e.g.,
to
requiring the implementation to set a "deallocation-requested" flag in
the
task object, to check such flags upon task termination, and to perform
any
deferred deallocations at that time).

Unfortunately, 13.11.2(9) gives permission to ignore any deallocation of
a
task object (or of an object containing a task object), even if its task
has
terminated.  Thus the standard provides no way for a programmer
allocating 
task objects to ensure the absence of a storage leak.

I am aware of Ada-83 implementations that interpreted the note in
RM83-13.10.1(7) to mean that any attempt to deallocate a task object
--even for a terminated task--could simply be ignored.  (In my opinion,
this was a misinterpretation, based on a failure to distinguish between
the
terms "task" and "task object" in that paragraph--and a failure to
recall
that "Note" paragraphs are not part of the standard anyway!)  However,
upward compatibility with Ada 83 did not require preservation of this
behavior, since no program (intentionally) depends on a deallocation
that
it requested not taking place!

-- 
Norman H. Cohen    ncohen@watson.ibm.com    
                   http://www.research.ibm.com/people/n/ncohen

Re: How to wait for task completion

[Stephen & Tammy House]

David C. Hoos, Sr. wrote:
> 
> wiljan <W.Derks@nl.cis.philips.com> wrote in article
> <01bba2e8$c45aad90$35208b82@wd>...
> > At a certain point I want to clean up the resources that the task is
> > using but this can only be done when the task is completed.
> 
> If the task can't clean up its own resources, why not provide a subprogram
> it can call just before it terminates?
> --
> David C. Hoos, Sr.,
> http://www.dbhwww.com
> http://www.ada95.com
Interesting, I just happen to have written this very thing this week.  A
task type is written such that its last act is to take itself out of a
global list of tasks.  It also frees the list node which held the
pointer to itself and frees itself (as the task is an object) with an
instance of Unchecked Deallocation.

Any guess as to whether the task terminates normally or disappears in a
flurry of segmentation faults as the object is returned to the heap?  It
doesn't seem to matter much, it goes away and the RTS doesn't complain
(or hasn't yet).  <Verdix compiler, SGI box, Ada83>