Q: Stopping a task running a long simulation
in [ADA]
|
From: Gautier write-only on 11 Mar 2010 08:08 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
From: Anh Vo on 11 Mar 2010 13:11 On Mar 11, 5:08 am, Gautier write-only <gautier_niou...(a)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
From: tmoran on 11 Mar 2010 19:24 > '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.
From: Gautier write-only on 11 Mar 2010 20:15 On 12 mar, 01:24, tmo...(a)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
From: Adam Beneschan on 11 Mar 2010 20:27
On Mar 11, 5:08 am, Gautier write-only <gautier_niou...(a)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 |