Re: [boost] [thread] 2 questions about thread interruption

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())
     {
       t.interrupt();
       t.join();
     }
   }};

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 :(

Best,
Vicente