1

I would like to have boost thread object being deleted together with exiting from thread entry function. Is it something wrong if I start the thread function and pass a shared pointer to object, which owns thread object instance and then, when thread function exits, it destroys the this object together with thread object at the same time?

EDIT: Maybe I will describe why I want to do that. I have to use low level dbus API. What I want to do is to create the adapter class, which will start its own thread and wait for incoming messages until the DISCONNECT message arrives. If it arrives I want to close the thread and kill the Adapter itself. The adapter is an Active Object, which runs the method sent to its scheduler. These methods put themselves on the scheduler queue once again after reading message from dbus. But if it is DISCONNECT message, they should not sent the method but just exit scheduler thread, destroying the Adapter object. hmmm looks like it is too complicated...

user2301299
  • 529
  • 1
  • 5
  • 15
  • it should be valid, a simpler version of you idea: http://stackoverflow.com/a/3974471/2183287 – fatihk Jun 14 '13 at 10:21
  • Why do you even need the boost::thread object alive? Since a thread's death is unpredictable for external code, that makes the thread object's lifetime unpredictable, which makes it effectively useless. And a thread should not access its own std::thread object. Have you considered simply `detach()`ing from the thread? – Sebastian Redl Jun 14 '13 at 12:21
  • looking at below answers, detaching thread without any way to monitor it is not a good idea. – user2301299 Jun 14 '13 at 13:16

3 Answers3

2

From the Boost.Thread documentation you can see that a thread object that is joinable should not be deleted, otherwise std::terminate will be called.

So you should assure that if the thread is joinable, either join() or detach() should be called in the destructor of the object owning the thread. Note: if the thread itself is destroying the object, join() is not an option. The thread would attempt to join itself, resulting in a deadlock.

However, if you keep these restrictions in mind, you can destroy a thread from within its own thread of execution.

Arne Mertz
  • 24,171
  • 3
  • 51
  • 90
1

You can do this, but you probably should not.

The main purpose of the boost::thread object is that you can monitor the associated thread. Having a thread monitor itself does not make much sense in most scenarios.

As was suggested by the other answers, you could just detach the thread and throw the boost::thread object away. Doing this is usually considered bad style, unless the monitoring responsibility has been transferred to another object first. For example, many simple worker threads set a future upon completion. The future already provides all the monitoring we need, so we can detach the thread.

You should never detach a thread completely such that you lose all means of monitoring it. You must at least be able to guarantee a clean shutdown, which becomes impossible for all but the most trivial threads if you detach them completely.

ComicSansMS
  • 51,484
  • 14
  • 155
  • 166
  • How the future let us to monitor thread? You mean just by waiting for the response from the worker thread? It will let us to block the program until all worker threads finishes? – user2301299 Jun 14 '13 at 13:14
  • Exactly. In case of trivial worker threads, that is often all the monitoring we need (see [std::async](http://en.cppreference.com/w/cpp/thread/async) for example). – ComicSansMS Jun 14 '13 at 13:48
0

I am not sure if that addresses your use case but it sounds to me like you don't have to do this.

The lifetime of the boost::thread object does not necessarily coincide with the thread itself. Meaning that if you don't care you can just as well start the thread, call detach() on it and have the object run out of scope. Then it is deleted but the thread will still run until it's function is finished. The only thing is, you won't be able to join it. So if your program finishes while the thread still runs it will crash.

In case you do care about this stuff, the question might be wrong because in this case you would store the objects and call join() on them before deleting.

  • Is it really true that program will crash if detached thread is still running? – user2301299 Jun 14 '13 at 13:07
  • Well, generally it will. Kinda random. Depending a bit on what the thread does and your OS. In your case, if you're just doing hobby or messing around you may just go and do it. In commercial grade SW this is a no-go. Just imagine the OS tearing down your process, deleting local and global variables and your abandoned thread still accessing them. This will cause a crash for example. If your thread is in sleep() or adding 1+1 you may get away with it ;-) But yeah, it's evil. –  Jun 14 '13 at 13:45
  • Assuming that somebody is using global variables... it is also not a good idea. OK so detached thread, which accesses only its own variables defined within its thread method cannot do anything wrong? – user2301299 Jun 14 '13 at 22:14