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 J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-12-07 16:24:50

Le 07/12/12 21:19, Gaetano Mendola a écrit :
> On 07/12/2012 20.53, Vicente J. Botet Escriba wrote:
>> Le 07/12/12 20:26, Gaetano Mendola a écrit :
>>> On 07/12/2012 19.03, Vicente J. Botet Escriba wrote:
>>>> Le 07/12/12 01:23, Gaetano Mendola a écrit :
>>>>>
>>>>> Even the implementation can be improved, even if it's thread safe it
>>>>> doesn't avoid to issue a join to an already joined thread, or for the
>>>>> matter to interrupt a thread already joined/interrupted.
>>>>>
>>>> I don't know if you comment has something to be with these two tickets
>>>>
>>>> https://svn.boost.org/trac/boost/ticket/7668: thread_group::join_all()
>>>> should check whether its threads are joinable
>>>
>>> Intersting, I saw the fix and as you can see it has a race condition
>>> there, indeed a thread can detach itself between the call to joinable
>>> and the join at that point even if the check was made when the join is
>>> issued the precondition doesn't hold anymore.
>>>
>>> Basically that is the question I'm asking: how can we be sure that a
>>> thread is joinable when we call the join on it, for sure checking the
>>> "joinable" has some problems. I have solved this in my thread group
>>> implementation with a flag saying if the thread was already
>>> joined or not and this works only because our threads do not detach
>>> them self so the thread group is the only responsible for the status
>>> change.
>>>
>>  From my point of view a thread in a thread_group is owned by the thread
>> group. Any direct operation on a thread belonging to the thread group
>> falls in undefined behavior.
>
> I do full agree, that's why the thread_group::create_thread has to 
> return void or at most the thread id.
yes a thread::id would be a better option.

> What can the user do with a pointer to the create thread? All members
> are not safe to be called apart two static functions.
You can remove a thread from a thread_group :)
> I believe not returning the thread pointer (that can not be touched
> anyway) would improve thread_group interface.
>
> > 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.

Best,
Vicente