Boost logo

Boost :

Subject: Re: [boost] [thread] 2 questions about thread interruption
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-04-19 14:36:36

Le 18/04/2016 23:50, Andrzej Krzemienski a écrit :
> 2016-04-18 23:42 GMT+02:00 Andrzej Krzemienski <akrzemi1_at_[hidden]>:
>> Hi,
>> I have two questions connected to thread interruption in Boost.Thread.
>> *1.* The docs say that interrupt_and_join_if_joinable is defined as
>> follows:
>> ```
>> struct interrupt_and_join_if_joinable{
>> void operator()(thread& t)
>> {
>> t.interrupt();
>> if (t.joinable())
>> {
>> t.join();
>> }
>> }};
>> ```
> Sorry, let me continue with the question. Is there a reason why
> t.interrupt() is called without checking if t is joinable? This looks
> uncomfortable to me that I would be potentially calling interrupt() on a
> not-a-thread.
Interrupting a not-a-thread should do nothing. I will add this to the
reference documentation.
However nothing prevents to implement it this way

   void operator()(thread& t)
     if (t.joinable())

I will do it.

> *2.* When I make a call to this_thread::wait_for(),
Do you mean sleep_for here?
> blocking for a long
> time in thread t2, and the instant later I call t2.interrupt() from another
> thread t1. Do I have to wait the long time until wait_for() stops blocking
> t2, or does thread_interrupted get called 'immediately' after interrupt()
> is called from t1?
It depends. If sleep_for is implemented using
nanosleep()/pthread_delay_np() there is no way to throw the
thread_interrupted exception. However, if it is implemented waiting on a
condition variable wait_for, then the exception will be throw before the
duration elapses.

Currently, sleep_for make use of nanosleep/pthread_delay_np when
available. The advantage been that the sleep is steady/monotonic.
> *3.* Does the support for interruption points require the other
> synchronization operations (like locks on mutexes) to be slower (in order
> to monitor interruption requests)?
Not for locks and mutex, but yes it will be a little bit slower for
condition variables, as we need to store the condition variable on which
a thread could be waiting for.

I've on my TODO list a task to build interuptible threads on top of raw
threads, but this will need to have also specific condition variables :(


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