Re: [boost] [thread 1.48] Multiple interrupt/timed_join leads to deadlock

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

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/thread-1-48-Multiple-interrupt-timed-join-leads-to-deadlock-tp4639403p4639866.html
Sent from the Boost - Dev mailing list archive at Nabble.com.