Q: Stopping a task running a long simulation

Q: Stopping a task running a long simulation

[Gautier write-only]

Hello,
Being still a bit new to tasking, I have a question of how to
terminate correctly a certain kind of task.
I have a task type which is waiting for running a potentially long
simulation; it is kind of a "daemon".
(the rationale of using a task type is that I have several simulations
that can be run in parallel, hence an array of these tasks).
Now this simulation occurs within a GUI, where the user might want to
stop it.
Here is the task type I've defined:

  task type Simulation_type is
    entry Start;
    entry Run( [some parameters] );
    entry Stop;
  end;

  Simulation: array(PF_version) of Simulation_type;

  task body Simulation_type is
  begin
    accept Start;
    loop
      select
        accept Stop;
        exit;
      or
        accept Run( [some parameters] ) do
          -- some quick parameter passing
        end Run;
        Compute( [some parameters] );
      or
        delay 0.2; -- relax
      end select;
    end loop;
  end Simulation_type;

For aborting the simulation, I have tried this (happens when the main
GUI window is destroyed):
    for v in PF_version loop
      abort Daemons.Simulation(v);
    end loop;
but (as expected if I've understood Barnes' chapter correctly), the
task waits for 'Compute' to complete.
At least, it is what happens with GNAT under Windows: despite the
above, the GUI closes but the program somehow is still alive and CPU-
busy.

I have an alternative to that.
'Compute' has a generic 'Feedback' procedure for showing progress.
I could with that way give a Boolean, user_abort, to 'Feedback', and
'Compute' would stop when an ad-hoc exception is raised, and return
normally on its own.
Meanwhile, I could call the 'Stop' entry which could be soon be
activated, since Compute would stop quickly, and the daemon task would
be terminated, and I could close the shop properly.

Now my question: is it the right way of doing it (I'm sure it will
work), or is there something more straightforward ?

TIA

Gautier

Re: Q: Stopping a task running a long simulation

[Anh Vo]

On Mar 11, 5:08 am, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> Hello,
> Being still a bit new to tasking, I have a question of how to
> terminate correctly a certain kind of task.
> I have a task type which is waiting for running a potentially long
> simulation; it is kind of a "daemon".
> (the rationale of using a task type is that I have several simulations
> that can be run in parallel, hence an array of these tasks).
> Now this simulation occurs within a GUI, where the user might want to
> stop it.
> Here is the task type I've defined:
>
>   task type Simulation_type is
>     entry Start;
>     entry Run( [some parameters] );
>     entry Stop;
>   end;
>
>   Simulation: array(PF_version) of Simulation_type;
>
>   task body Simulation_type is
>   begin
>     accept Start;
>     loop
>       select
>         accept Stop;
>         exit;
>       or
>         accept Run( [some parameters] ) do
>           -- some quick parameter passing
>         end Run;
>         Compute( [some parameters] );
>       or
>         delay 0.2; -- relax
>       end select;
>     end loop;
>   end Simulation_type;
>
> For aborting the simulation, I have tried this (happens when the main
> GUI window is destroyed):
>     for v in PF_version loop
>       abort Daemons.Simulation(v);
>     end loop;
> but (as expected if I've understood Barnes' chapter correctly), the
> task waits for 'Compute' to complete.
> At least, it is what happens with GNAT under Windows: despite the
> above, the GUI closes but the program somehow is still alive and CPU-
> busy.
>
> I have an alternative to that.
> 'Compute' has a generic 'Feedback' procedure for showing progress.
> I could with that way give a Boolean, user_abort, to 'Feedback', and
> 'Compute' would stop when an ad-hoc exception is raised, and return
> normally on its own.
> Meanwhile, I could call the 'Stop' entry which could be soon be
> activated, since Compute would stop quickly, and the daemon task would
> be terminated, and I could close the shop properly.
>
> Now my question: is it the right way of doing it (I'm sure it will
> work), or is there something more straightforward ?
>

There is another alternative to shut them down. That is to replace
delay 0.2 statement by terminate alternative.

Calling Stop entry to shutdown the task is the gentle way to terminate
a task. How about to generate a signal to call Stop entry when the GUI
is closed.

Anh Vo

Re: Q: Stopping a task running a long simulation

[tmoran]

> 'Compute' has a generic 'Feedback' procedure for showing progress.
> I could with that way give a Boolean, user_abort, to 'Feedback', and
> 'Compute' would stop when an ad-hoc exception is raised, and return
> normally on its own.

  Think of a motor and its control panel.  The panel does read-only access
to certain information in the motor, its speed for instance, which the
panel displays.  The panel can also write certain information, like Stop,
to a switch that the motor periodically (every rotation?) checks.  Compute
is your motor and the GUI is the control panel.  Progress information
is regularly written by Compute to a record, which is periodically
read by the GUI, and control information is written as needed by the
GUI and regularly read by Compute.

Re: Q: Stopping a task running a long simulation

[Gautier write-only]

On 12 mar, 01:24, tmo...@acm.org wrote:
> > 'Compute' has a generic 'Feedback' procedure for showing progress.
> > I could with that way give a Boolean, user_abort, to 'Feedback', and
> > 'Compute' would stop when an ad-hoc exception is raised, and return
> > normally on its own.
>
>   Think of a motor and its control panel.  The panel does read-only access
> to certain information in the motor, its speed for instance, which the
> panel displays.  The panel can also write certain information, like Stop,
> to a switch that the motor periodically (every rotation?) checks.  Compute
> is your motor and the GUI is the control panel.  Progress information
> is regularly written by Compute to a record, which is periodically
> read by the GUI, and control information is written as needed by the
> GUI and regularly read by Compute.

Thanks - it is a perfect metaphore. And be reassured, I have no
trouble programming this. My question is: would you recommend that way
(have a mechanism to tell the motor to stop) in order to have a chance
in a reasonable time to stop the "runner daemon" task in its turn ? I
am tempted to do so. I was just exploring possibilities of stopping
the daemon and the motor in a direct and less polite way, but still
good Ada practice.
Gautier

Re: Q: Stopping a task running a long simulation

[Adam Beneschan]

On Mar 11, 5:08 am, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> Hello,
> Being still a bit new to tasking, I have a question of how to
> terminate correctly a certain kind of task.
> I have a task type which is waiting for running a potentially long
> simulation; it is kind of a "daemon".
> (the rationale of using a task type is that I have several simulations
> that can be run in parallel, hence an array of these tasks).
> Now this simulation occurs within a GUI, where the user might want to
> stop it.
> Here is the task type I've defined:
>
>   task type Simulation_type is
>     entry Start;
>     entry Run( [some parameters] );
>     entry Stop;
>   end;
>
>   Simulation: array(PF_version) of Simulation_type;
>
>   task body Simulation_type is
>   begin
>     accept Start;
>     loop
>       select
>         accept Stop;
>         exit;
>       or
>         accept Run( [some parameters] ) do
>           -- some quick parameter passing
>         end Run;
>         Compute( [some parameters] );
>       or
>         delay 0.2; -- relax
>       end select;
>     end loop;
>   end Simulation_type;
>
> For aborting the simulation, I have tried this (happens when the main
> GUI window is destroyed):
>     for v in PF_version loop
>       abort Daemons.Simulation(v);
>     end loop;
> but (as expected if I've understood Barnes' chapter correctly), the
> task waits for 'Compute' to complete.
> At least, it is what happens with GNAT under Windows: despite the
> above, the GUI closes but the program somehow is still alive and CPU-
> busy.

I'm not sure you've understood correctly...or maybe I haven't
understood the problem correctly...  When the task is aborted, it
doesn't *need* to wait for Compute to complete.  The language leaves
it up to implementations to decide how quickly to abort, as long as
the abort happens at or before the next "abort completion point".
However, I'd be surprised by the behavior if you abort the task but
Compute keeps using CPU for any length of time.  I don't know GNAT
really well; maybe there are configuration options that you need to
select in order to get the more expected behavior.  In any case,
however, I know of nothing in the language that says that the task
must wait for Compute to complete before it aborts, unless Compute is
executing a very long abort-deferred operation, which seems unlikely
(see 9.8(9-11)---you didn't put the whole computation in a controlled
Initialize routine, I hope???).

Anyway, based on looking at the section on "abort completion
point" (9.8(15-19)), I suppose that if you can't get the behavior you
want with configuration options, you could do it by having Compute
perform a "delay 0.0" statement periodically.


> I have an alternative to that.
> 'Compute' has a generic 'Feedback' procedure for showing progress.
> I could with that way give a Boolean, user_abort, to 'Feedback', and
> 'Compute' would stop when an ad-hoc exception is raised, and return
> normally on its own.

You're saying Feedback would check something to see if another task
wants to abort it, and raise an exception if the answer is "yes"?  I'd
use a protected object for that (as opposed to a global Boolean
user_abort as you seem to be suggesting).  But I think this would work
and might be better than the "abort" meat-axe approach.

                                -- Adam

Re: Q: Stopping a task running a long simulation

[Gautier write-only]

> You're saying Feedback would check something to see if another task
> wants to abort it, and raise an exception if the answer is "yes"?

That's it (the exception being only internal to Compute, for reaching
its end quickly; probably I'll use an 'exit when' instead). The
feedback procedure would look like:
http://unzip-ada.sourceforge.net/za_html/zip__ads.htm#218_8

> I'd use a protected object for that (as opposed to a global Boolean
> user_abort as you seem to be suggesting).

Thanks - indeed in a way or the other, there would a Boolean written
(and only written) by the GUI action and read (and only read) by
Feedback, randomly. Isn't the pragma Volatile sufficient in such a
case ?

> But I think this would work and might be better than the "abort" meat-axe approach.

Thanks for the advice - indeed thinking further, it would be also
useful for a "Stop" UI command, where the simulation is just
interrupted, but the daemon would be kept alive for other simulations.

Gautier

Re: Q: Stopping a task running a long simulation

[Gautier write-only]

> However, I'd be surprised by the behavior if you abort the task but
> Compute keeps using CPU for any length of time.

Yes, that would be a bit counter-intuitive (since the call to Compute
is part of the task).
What happens is that the abort is in the main window's Destroy method,
which occurs after its closing, so I guess it is just waiting at the
abort statement. And if I understand well, a delay 0.0 in the main
Compute loop would facilitate the aborting (I'll experiment it).
Anyway, in the end I'll use the more deterministic way discussed
elsewhere.
Thanks
Gautier