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
richardsimnettAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

evilrixSenior Software Engineer (Avast)Commented:
The thread group takes care of it all for you.
0
evilrixSenior Software Engineer (Avast)Commented:
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
0
richardsimnettAuthor Commented:
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
0
Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

evilrixSenior Software Engineer (Avast)Commented:
The point of a thread group (think thread pool) is that you create a group of threads and keep re-using them. In other words, no new threads are created other than those you added by calling the add() method.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MXProCommented:

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.
0
evilrixSenior Software Engineer (Avast)Commented:
@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.
0
richardsimnettAuthor Commented:
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.

0
evilrixSenior Software Engineer (Avast)Commented:
Exactly :)
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.