[statechart] Question about do activities
In the boost::statechart documentation, on the UML mapping page, it says this about do activities: “A do activity can be simulated with a separate thread that is started in the entry action and cancelled (!) in the exit action of a particular state.” What's the significance of the exclamation point here? Is it suggesting that the thread should be killed rather than joined? I'm considering boost::statechart for a design where do activities will be a fundamental feature, so I'm wondering whether we might run into problems with this.
I see that I'm way behind the times on boost::thread - I hadn't realized that cancellation had been added to it. So, I'll rephrase the question - from the point of view of boost::statechart, is there a reason to prefer cancellation over some other means of stopping a thread, like calling a stop() function and then join()?
I see that I'm way behind the times on boost::thread - I hadn't realized that cancellation had been added to it.
Could you please point out where you found "cancellation" in boost.thread docs? Or probably you mean "interruption"?
So, I'll rephrase the question - from the point of view of boost::statechart, is there a reason to prefer cancellation over some other means of stopping a thread, like calling a stop() function and then join()?
When you "cancel" or stop another thread by any means and then join() it from within the thread that processes state-chart events, the state-machine would not process events until join() returns. Whether this is the desired behavior or not - depends on the design of your application.
Hi Bill
I see that I'm way behind the times on boost::thread - I hadn't realized that cancellation had been added to it.
Interruption has been added to it, which is not what I had in mind with cancellation. The former only allows to "stop" a thread at predefined points (usually when the thread is waiting on a lock or a condition variable, etc. The latter allows to "stop" a thread anywhere (even when it is executing a while (true) {} loop). In order to be useful for the general case, both actions must lead to an exception being thrown in the target thread. An exception is required so that acquired resources can be cleaned up correctly, which is why I put the word stop in quotes above. The thread isn't really stopped immediately, it's just instructed to start cleaning up as soon as possible.
So, I'll rephrase the question - from the point of view of boost::statechart, is there a reason to prefer cancellation over some other means of stopping a thread, like calling a stop() function and then join()?
Boost.Thread doesn't offer stop(). Which threading API do you have in mind? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Hi Andreas, Ok, I was thinking that you were equating cancellation with interruption. My reference to a stop() function was meant as a placeholder for any kind of function (other than cancellation or interruption) that tells an active object to quit processing and clean up after itself. A function like that is needed if cancellation/interruption aren't available. So, would the following statements be true? - boost::statechart imposes no requirements on do-activity threads, other than that they stop when instructed to (by whatever means) and that they clean up after themselves. - Any timing requirements on how quickly the thread actually exits are determined by the design of the application; boost::statechart itself imposes no such requirements. Bill On Wed, Apr 22, 2009 at 2:11 AM, Andreas Huber < ahd6974-spamboostorgtrap@yahoo.com> wrote:
Hi Bill
I see that I'm way behind the times on boost::thread - I hadn't realized
that cancellation had been added to it.
Interruption has been added to it, which is not what I had in mind with cancellation. The former only allows to "stop" a thread at predefined points (usually when the thread is waiting on a lock or a condition variable, etc. The latter allows to "stop" a thread anywhere (even when it is executing a while (true) {} loop).
In order to be useful for the general case, both actions must lead to an exception being thrown in the target thread. An exception is required so that acquired resources can be cleaned up correctly, which is why I put the word stop in quotes above. The thread isn't really stopped immediately, it's just instructed to start cleaning up as soon as possible.
So, I'll rephrase the question - from the point of view of
boost::statechart, is there a reason to prefer cancellation over some other means of stopping a thread, like calling a stop() function and then join()?
Boost.Thread doesn't offer stop(). Which threading API do you have in mind?
Regards,
-- Andreas Huber
When replying by private email, please remove the words spam and trap from the address shown in the header.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ok, I was thinking that you were equating cancellation with interruption. My reference to a stop() function was meant as a placeholder for any kind of function (other than cancellation or interruption) that tells an active object to quit processing and clean up after itself. A function like that is needed if cancellation/interruption aren't available.
Ok.
So, would the following statements be true?
- boost::statechart imposes no requirements on do-activity threads, other than that they stop when instructed to (by whatever means) and that they clean up after themselves.
Correct.
- Any timing requirements on how quickly the thread actually exits are determined by the design of the application; boost::statechart itself imposes no such requirements.
Right. I'm sure you already know that but a thing to remember is that stopping/cancelling a thread can be a relatively lengthy process, which is why I added the exclamation mark in the docs. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (3)
-
Andreas Huber -
Bill Clark -
Igor R