Boost logo

Boost :

Subject: Re: [boost] [thread 1.48] Multiple interrupt/timed_join leads to deadlock
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-12-11 10:13:48

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, ...


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at