multitasking: finishing execution

multitasking: finishing execution

[chris.danx]

Hi,

Is calling the entry finish sufficient to terminate the task?  The code of
the entry isn't the concern, but the behaviour of entries.  Consider the
following procedure

procedure finish_tasks is
begin
   some_task.finish;                                     -- 1
   ada.text_io.put ("some_task should have terminated"); -- 2
end finish_tasks;


-- sample task code
--
loop
   select
      accept Finish;
      exit;
   else
      -- do some processing (sample code)
      --
      if x < integer'last then
         x := x + 1;
      end if;
   end select;
end loop;


Can the call to some_task.finish time out?  If it can there's no guarantee
that the task has finished executing before the call to ada.text_io.put is
executed and the program may fail to terminate because it has running tasks,
correct?

As you can see I'm a little confused by the fact that an entry can time out.
Does it mean that the call can time out no matter what or that the task has
to contain the appropriate code for an entry call to time out (such as a
delay altenative)?  i.e. will the procedure wait indefinitely for the task
to terminate or will it abandon the entry call after some time elapses?

If the code doesn't work as intended, what solution would you recommend?  Is
there a better way?


Thanks,
Chris

Re: multitasking: finishing execution

[Nige]

chris.danx wrote:
> Hi,
> 
> Is calling the entry finish sufficient to terminate the task?  The code of
> the entry isn't the concern, but the behaviour of entries.  Consider the
> following procedure
> 
> procedure finish_tasks is
> begin
>    some_task.finish;                                     -- 1
>    ada.text_io.put ("some_task should have terminated"); -- 2
> end finish_tasks;
> 
> 
> -- sample task code
> --
> loop
>    select
>       accept Finish;
>       exit;
>    else
>       -- do some processing (sample code)
>       --
>       if x < integer'last then
>          x := x + 1;
>       end if;
>    end select;
> end loop;
> 
> 
> Can the call to some_task.finish time out?  If it can there's no guarantee
> that the task has finished executing before the call to ada.text_io.put is
> executed and the program may fail to terminate because it has running tasks,
> correct?
> 
> As you can see I'm a little confused by the fact that an entry can time out.
> Does it mean that the call can time out no matter what or that the task has
> to contain the appropriate code for an entry call to time out (such as a
> delay altenative)?  i.e. will the procedure wait indefinitely for the task
> to terminate or will it abandon the entry call after some time elapses?
> 
> If the code doesn't work as intended, what solution would you recommend?  Is
> there a better way?

select
    accept Finish;
else
    -- do code
    ....
end select;

will only process the accept if there is an outstanding call to it. For 
a call to timeout, you need to use:

select
    some_task.finish;
or
    delay <time>;
end select;

which will wait for up to <time> seconds for the call to be accepted, 
before giving up.

Also, in the following, it will wait for <time> seconds before executing 
the code after it, unless Finish is called into the meantime...

select
    accept Finish;
or
    delay <time>;
    -- do code
    ....
end select;


Hope that makes sense...

Nige

Re: multitasking: finishing execution

[Stephen Leake]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> Hi,
> 
> Is calling the entry finish sufficient to terminate the task?  The code of
> the entry isn't the concern, but the behaviour of entries.  Consider the
> following procedure
> 
> <snip example code>

The "Ada way" to terminate a task is with a "terminate" alternative:

select
   accept <some entry>
or
   terminate;
end select;

See ARM 9.7.2.

It is often not obvious how to set up your task to both get some work
done and be ready to quit when told to. But it is important to get it
right :).

-- 
-- Stephe

Re: multitasking: finishing execution

[chris.danx]

"Nige" <nigel.scott@uk.thalesgroup.com> wrote in message
news:3D11CF27.90401@uk.thalesgroup.com...

> select
>     accept Finish;
> else
>     -- do code
>     ....
> end select;
>
> will only process the accept if there is an outstanding call to it.

If a handler calls Finish will it wait indefinitely for the task to accept
it?  That was the original question, although in retrospect the first post
was just confusing.


The problem involves a window and two tasks, a watcher and a builder.  A
watcher scans the keyboard, placing any keypresses corresponding to commands
into a protected object, unless Finish is called at which point the watcher
terminates.  The builder retrieves a keypress from the protected object and
does some processing with it until it recieves a call to Finish, when it
terminates.

Upon creation of the window, a handler 'on_create' starts both tasks.  When
the user quits the application (more precisely closes a window, which in
this case happens to be the main window) the on_destroy handler terminates
the task.

My concern is what would happen if the call to the Finish was not accepted
before any time limit expired.  Cohen states that a task must finish
execution before a program can terminate (which makes sense), if the call
wasn't accepted and subsequenctly abandoned the program would fail to
terminate.

If the builder processes information too quickly, any animation will be done
and over with before the user realises it (also if the redraw method is
called continuously it will crash the system, which happened when I forgot
to clear the flag which records if a keypress is available).  To alleviate
this problem a delay alternative has been added to the code, which waits
around 20ms before doing any processing.  (A better solution might be to use
a protected object describing the state and another task which translates
this and draws it to the screen, but this is just practise with tasks and
gwindows before the main project).

If a call to an entry is placed after the delay alternative expires will the
entry succeed (be accepted by the task) in the next iteration (assuming the
next iteration is free to proceed)?  I think it will since entries queue,
but just want to make sure.


Thanks,
Chris

Re: multitasking: finishing execution

[chris.danx]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:usn3it31c.fsf@gsfc.nasa.gov...


> The "Ada way" to terminate a task is with a "terminate" alternative:

Yep except that task will only respond to entries.  The problem requires
that it do useful work until it is quit.  That is, the task must execute a
sequence of events repeatedly and not in response to entries, but quit when
asked to.

> select
>    accept <some entry>
> or
>    terminate;
> end select;

That forbids the use of the else block (and a delay which is currently in
charge of executing the real work the task must do.  See the ARM section
9.7.1 points 8 through 12.

> See ARM 9.7.2.

Not ARM 9.7.1 and 9.3?  9.7.2 deals with timed entries.

> It is often not obvious how to set up your task to both get some work
> done and be ready to quit when told to. But it is important to get it
> right :).

Of course :)


Chris

Re: multitasking: finishing execution

[Stephen Leake]

"chris.danx" <spamoff.danx@ntlworld.com> writes:

> "Nige" <nigel.scott@uk.thalesgroup.com> wrote in message
> news:3D11CF27.90401@uk.thalesgroup.com...
> 
> > select
> >     accept Finish;
> > else
> >     -- do code
> >     ....
> > end select;
> >
> > will only process the accept if there is an outstanding call to it.
> 
> If a handler calls Finish will it wait indefinitely for the task to accept
> it?  

Yes.


-- 
-- Stephe

Re: multitasking: finishing execution

[Ted Dennison]

"chris.danx" <spamoff.danx@ntlworld.com> wrote in message news:<64qQ8.9894$ZP1.1899365@news11-gui.server.ntli.net>...
> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:usn3it31c.fsf@gsfc.nasa.gov...
> 
> 
> > The "Ada way" to terminate a task is with a "terminate" alternative:
> 
> That forbids the use of the else block (and a delay which is currently in
> charge of executing the real work the task must do.  See the ARM section
> 9.7.1 points 8 through 12.

That's why I'm much more likely to have a "Quit" entry.