Boost logo

Boost :

Subject: Re: [boost] [thread 1.48] Multiple interrupt/timed_join leads to deadlock
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2012-12-12 03:19:01

On 12/12/2012 08.33, Vicente J. Botet Escriba wrote:
> Le 12/12/12 00:32, Gaetano Mendola a écrit :
>> On 11/12/2012 21.23, Vicente J. Botet Escriba wrote:
>>> Le 11/12/12 19:12, Gaetano Mendola a écrit :
>>>> On 11/12/2012 16.13, Vicente Botet wrote:
>>>>> Gaetano Mendola-3 wrote
>>>>>> 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.
>>>> It can manage without pestering the developers the fact that one
>>>> entity spawns a batch of threads and then wait for the completion
>>>> waiting on
>>>> the join() while another entity (an user interface as example) can
>>>> stop the whole process if it's taking too much time. Otherwise as soon
>>>> someone performs a boost::thread_group::join then nothing can be done
>>>> from outside to stop the process. It seems a natural use to me.
>>> OK I think I understand your use case. Here it is an alternative that
>>> don't use any mutex to protect the group of thread.
>>> I will choose and owner of all these threads, insert them on a
>>> container. Only this thread is able to join/interrupt the threads.
>>> I will use some way to transfer the request from the user interface
>>> thread to the owner that this is taking too much time (using atomic?).
>>> The owner will try to join each thread using try_join_until with the
>>> desired expiration time. If the thread is joined the thread is removed
>>> from the container. If there is a timeout the owner will check the
>>> protected state 'take_too_much_time' and will interrupt all the other
>>> threads and then join all of them. As you can see the contention is
>>> reduced.
>>> Note that this is a specific behavior that can not be added to the
>>> thread_group class. I will be for the addition of an algorithm/free
>>> function that try to join the threads on a container/range during a
>>> given duration or until an expiration time (removing the joined
>>> threads).
>> I don't know who the boost thread maintainer is and how/who decides
>> if a design is good to be implemented or it work the other way around?
> Here I was talking about my alternative solution.
>>>>>> 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.
>>>> This is true if the thread_group does not permits to be used by
>>>> multiple
>>>> threads interrupting/joining.
>>> I understand now why you did this way. But I will not do that.
>> Then the maintainer is you?
> Here I was talking as a user, that is, that I will not use the design of
> your application.
> And yes, I'm the maintainer with Anthony Williams that is the principal
> author.
>>>>>> 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?
>>>> Sure, if a thread performs a closed loop:
>>>> <snip>
>>>> then it goes in starvationm we have observed this (even in a
>>>> deterministic way), then I had to make the two interrupt/timed_join on
>>>> the thread handler fair each other.
>>>> Our platform is a linux platform with a 3.2.0 kernel.
>>> IMO, only one thread should join/interrupt all the threads. This avoid
>>> all these issues.
>> Avoid the issues at thread group level, but those issues will be present
>> into an upper layer.
> Maybe. Have you identified these issues on the design I have proposed
> above?

Of course not if thread_group is treated as not thread safe indeed you
avoid all those issues at once.

>> It seems it was coded when it was not a problem for a thread to be
>> joined even if joined/interrupted.
> You are right, the last change in thread had some some undesirable
> impacts on thread_group. IMO, the two fixes I reported in this thread
> resolve the issues.
> Please let me know if this is not the case.

It solves the issue yes. A consideration I can do is to completely
remove the mutex protection inside the thread_group because it's
useless not being a class meant to be used by multiple threads, also
due the fact it is an only header class the inspection of
implementation it gives false expectations.

Gaetano Mendola

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