richardsimnett
asked on
A question about boost::thread_group
Hello,
So I am attempting to learn multi-threading in CPP using boosts thread pool (thread_group) and had a question come up regarding management of the thread pool.
So the library is simple enough, initialize a thread group and then call create_thread with the pointer to the function you want to execute within the thread. The thread executes til it is finished, and then terminates. So far this is pretty standard, my question comes after it has been terminated and detached by the OS.
Once this occurs do I have to physically clean up its memory space? In other words, when you create_thread it returns a thread*. Should I be storing that pointer somewhere, and intermittently check to see if the thread is still active? If its not active, do I have to perform the delete to clear the memory space off of the heap?
Please advise. If I do need to do this, what is the simplest solution to manage this? An array of pointers that I traverse to check the status and deallocate them if they arent running?
Worth 500 points.
Thanks,
Rick
So I am attempting to learn multi-threading in CPP using boosts thread pool (thread_group) and had a question come up regarding management of the thread pool.
So the library is simple enough, initialize a thread group and then call create_thread with the pointer to the function you want to execute within the thread. The thread executes til it is finished, and then terminates. So far this is pretty standard, my question comes after it has been terminated and detached by the OS.
Once this occurs do I have to physically clean up its memory space? In other words, when you create_thread it returns a thread*. Should I be storing that pointer somewhere, and intermittently check to see if the thread is still active? If its not active, do I have to perform the delete to clear the memory space off of the heap?
Please advise. If I do need to do this, what is the simplest solution to manage this? An array of pointers that I traverse to check the status and deallocate them if they arent running?
Worth 500 points.
Thanks,
Rick
evilrix
The thread group takes care of it all for you.
More specifically...
Destructor
~thread_group();
Effects:
Destroy *this and delete all boost::thread objects in the group.
http://www.boost.org/doc/libs/1_43_0/doc/html/thread/thread_management.html
Destructor
~thread_group();
Effects:
Destroy *this and delete all boost::thread objects in the group.
http://www.boost.org/doc/libs/1_43_0/doc/html/thread/thread_management.html
ASKER
evilrix,
ok so it happens when I destroy the thread group, but lets say the thread group isnt destroyed at all during the lifetime of the program? Will the heap build up over and over with all the additional executing threads causing runaway memory usage (a memory leak) if I dont physically release the memory?
Thanks,
Rick
ok so it happens when I destroy the thread group, but lets say the thread group isnt destroyed at all during the lifetime of the program? Will the heap build up over and over with all the additional executing threads causing runaway memory usage (a memory leak) if I dont physically release the memory?
Thanks,
Rick
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Look at it from this perspective.
If you create it in the execute loop then release it there. If you create it outside the execute loop and share it with the thread then clean up after the thread returns.
It is not advisable to clean up in a destructor for an object instance that encapsulates memory that is created outside the scope of the thread unless a clear line of ownership can be established. The trick is to realize who owns what. If the thread owns it then clean up prior to exiting the execute method because the process will terminate prior to the destructor being called.
Remember this that the thread is not the class and the class is not the thread. The class meerly wraps the thread. In most cases the thread proc is called which dereferences a class instance which maps into the class instance and calls the execute method. When that is complete the Thread Proc Exits meaning the Thread is terminated. Some implementations try to get cute here and call the destructor for the class pior to the ThreadProc exit to free the memory.
Check your stack either in a debugger or using a stack trace, you will see if your destructor is being called from the ThreadProc or from the outside world after the thread has exited.
Hope this helps.
@MXPro, I think you might have got the wrong end of the stick here. The asker just wants to know if they need to take any action to clean up the threads created when the add() method of thread_group is called. The answer is, "no", because the destructor of thread_group does that for you. If the thread itself allocates memory the, of course, that needs to also clean it up before the thread terminates but that is not (as I read the question) what the asker is referring too.
ASKER
evilrix,
I got it. That clarifies a question I had about the boost documentation. I didnt understand the thread state Not_A_thread but I get it now, that is the non-running thread in the pool. Since its just "idle" it doesnt need to be deallocated. That makes total sense to me now.
Thank you.
I got it. That clarifies a question I had about the boost documentation. I didnt understand the thread state Not_A_thread but I get it now, that is the non-running thread in the pool. Since its just "idle" it doesnt need to be deallocated. That makes total sense to me now.
Thank you.
Exactly :)