Gaetano Mendola-3 wrote
On 07/12/2012 22.24, Vicente J. Botet Escriba wrote:
Le 07/12/12 21:19, Gaetano Mendola a écrit :
On 07/12/2012 20.53, Vicente J. Botet Escriba wrote:
I'm for deprecating it, as I posted already sometime ago, but of course I'm for fixing the bugs I could be introduced by recent modification in other parts of the library. Anyway, before deprecating it, we need an alternative. Maybe you have already a concrete proposal and you can submit it to Boost.
I should rework our thread group to adapt it to new 1.52 interface. Great. It will be a pleasure to review it.
Attached my first proposal, I don't know if this is the correct way to submit it.
It depends on whether you want to submit an independent library. This has the advantage that you don't have to be backward compatible.
I have named it Thread_Group (capitalized) to not conflict with old thread_group implementation.
1) Thread group is now thread safe, it can be used concurrently by multiple threads
Why a thread group should be inherently thread-safe? It seems to me that having a thread container is already useful.
2) thread_group now maintains a list of handlers with the responsibility to: -) Avoid join and interrupts to be called concurrently on a thread -) Avoid to call join on a joined thread -) Avoid to call interrupt on a joined/interrupt thread
IMO, all the threads in a thread_group are owned by the group, and use move semantics, no need to use pointer to threads. As a consequence there is no need for the handler/wrapper.
3) Added join_any with the semantic to wait of any of the threads to terminate.
I don't like the implementation polling on all the threads to see if one of them has ended. Maybe the use of at_thread_exit could help. If all the threads of a thread group are created with the create_thread function, an alternative is to use a decorator of the user function that can signal when the thread has been finished. This behavior is quite close to futures.
3) create_thread now returns a thread::id *this is a break change*, what we can do now is to leave the create_thread as it is (returning a thread pointer) but returning not a real thread but a class inherited by thread allowing only the get_id method on it (other methods should be implemented with throw("method not callable").
Do you really need to remove threads? I will even go for don't returning anything? I will remove also the add_thread function.
4) Due the fact mutex are not fair a thread issuing an interrupt_all most likely will go in starvation if a thread is issuing a join_all (especialy if the group contains a single thread). I can work at it.
Could you clarify your concern? Why you have needed to change the implementation of join_all? It seems more complex now. As I said I'm for deprecating thread_group in Boost.Thread. The implementation you are proposing has not changed my mind. I would prefer an approach where data structures (containers) and algorithms (join, interrupt, ...) are separated, thread-safety is not mandatory, ... Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/thread-1-48-Multiple-interrupt-timed-join... Sent from the Boost - Dev mailing list archive at Nabble.com.