thread_group behavior question
I've been using Boost for several months now, and I must say I've been very happy with it. I've primarily been using the threads and regex stuff from the library, and I have a question regarding the behavior of the thread_group.join_all method. In my current situation, I have a thread_group which launches several threads of execution for background servers, on an as-needed basis. If it becomes necessary to shutdown those background servers, I issue a join_all on the thread_group to wait for all activity to cease, then I can clear up the server instances themselves. If I issue a join_all from a thread and, while waiting for the join_all to exit, another thread creates a thread within my thread_group, what is expected? Will the join_all now wait for the original threads, as well as the newcomer, or will it only wait on the threads which were running at the time the join_all was called?? Thanx, Steve Dussinger
I've been using Boost for several months now, and I must say I've been very happy with it. I've primarily been using the threads and regex stuff from the library, and I have a question regarding the behavior of the thread_group.join_all method.
In my current situation, I have a thread_group which launches several threads of execution for background servers, on an as-needed basis. If it becomes necessary to shutdown those background servers, I issue a join_all on the thread_group to wait for all activity to cease, then I can clear up the server instances themselves.
If I issue a join_all from a thread and, while waiting for the join_all to exit, another thread creates a thread within my thread_group, what is expected?
Good question. Currently, the add_thread() or create_thread() will block until the join_all() is finished, so the new thread will be added to an empty thread_group. This is, however, probably not what's wanted, and I'm working on this very issue.
Will the join_all now wait for the original threads, as well as the newcomer, or will it only wait on the threads which were running at the time the join_all was called??
Only those present when join_all() was called (and worse, the addition of the new thread blocks until the join_all() completes). I can fix the blocking behavior, but the question then becomes which of the two alternatives is found to be more appropriate: threads added during a join_all() call are waited for as well, or only the threads currently in the group are joined. I'm leaning towards the former. -- William E. Kempf wekempf@cox.net
Thanx for the quick reply, William.... As a followup, I need to be able to get around the blocking of the thread_group while waiting, so I'm thinking of creating a new group class which contains a thread_group and exposes a join_current method to join on the currently running set of threads only. This leads to a further question: If I'm running in a thread that was allocated as part of a thread_group (call it thread A) and I spawn a new thread (thread B) is the new thread (thread B) a member of the same thread_group as its parent (thread A) or is it not part of any thread group? (Assuming that I create the thread directly and not using thread_group.create_thread, of course :-))... Thanx, Steve Dussinger
sdussin said:
Thanx for the quick reply, William....
As a followup, I need to be able to get around the blocking of the thread_group while waiting, so I'm thinking of creating a new group class which contains a thread_group and exposes a join_current method to join on the currently running set of threads only.
This leads to a further question: If I'm running in a thread that was allocated as part of a thread_group (call it thread A) and I spawn a new thread (thread B) is the new thread (thread B) a member of the same thread_group as its parent (thread A) or is it not part of any thread group? (Assuming that I create the thread directly and not using thread_group.create_thread, of course :-))...
It's not part of any thread_group. It sounds like you're coming from a Java background? The thread_group isn't quite the same here as the ThreadGroup in Java. I've contemplated whether or not we should have a Java like thread_group semantic, but haven't really been swayed to it yet, and have kept our thread_group very simplistic. In fact, historically the only reason for boost::thread_group is to make it more convenient to spawn several threads in a loop and manage their lifetimes... and as such there's even been discussion of whether or not this concept should do any synchronization at all. -- William E. Kempf wekempf@cox.net
participants (2)
-
sdussin <sdussin1＠tampabay.rr.com> -
William E. Kempf