• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1000
  • Last Modified:

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
0
richardsimnett
Asked:
richardsimnett
  • 5
  • 2
1 Solution
 
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
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
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
 
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now