Subject: Re: [boost] [thread 1.48] Multiple interrupt/timed_join leads to deadlock
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2012-12-07 15:19:19
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.
What can the user do with a pointer to the create thread? All members
are not safe to be called apart two static functions.
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.
Regards
Gaetano Mendola