Re: [Xenomai-help] pthread cancelation and scheduling magics

[Wolfgang Grandegger <wg@domain.hid>]

Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Grandegger wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Wolfgang Grandegger wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> Wolfgang Grandegger wrote:
>>>>>>>> Running under gdb shows:
>>>>>>>>
>>>>>>>>   Program received signal SIGSEGV, Segmentation fault.
>>>>>>>>   [Switching to Thread 0x4885d4b0 (LWP 1127)]
>>>>>>>>   0x0ff49100 in pthread_cancel () from /lib/libpthread.so.0
>>>>>>>>   (gdb) where
>>>>>>>>   #0  0x0ff49100 in pthread_cancel () from /lib/libpthread.so.0
>>>>>>>>   #1  0x10001d64 in ctrl_func (parm=0x0) at cancel-test.c:104
>>>>>>>>   #2  0x0ffa98e4 in __pthread_trampoline ()
>>>>>>>>      from /home/wolf/xenomai/lib/libpthread_rt.so.1
>>>>>>>>   #3  0x0ff42a6c in start_thread () from /lib/libpthread.so.0
>>>>>>>>   #4  0x0fdd18a0 in clone () from /lib/libc.so.6
>>>>>>>>   Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>>>>>>>
>>>>>>>> Is pthread_cancel used from the Linux pthread library? And
>>>>>>>> pthread_testcancel() as well?
>>>>>>> Yes, and I guess, as you said, that it happens because calc_func is dead
>>>>>>> when you try and cancel it.
>>>>>> Yep, but it should not crash.
>>>>> The spec says:
>>>>> The pthread_cancel() function may fail if:
>>>>>
>>>>> [ESRCH]
>>>>>     No thread could be found corresponding to that specified by the
>>>>> given thread ID.
>>>>>
>>>>>
>>>>> So, it is a "may", returning ESRCH, as Xenomai does in kernel-space, is
>>>>> not mandatory.
>>>> I also got the return value ESRCH in another test. Nevertheless, a crash
>>>> is not the expected behaviour, to say the least. Here pthread_cancel()
>>>> obvoiusly get's interrupted and the calc_thread continues. Is it
>>>> possible that pthread_cancel() switches to secondary mode?
>>> pthread_cancel switches to secondary mode if it has to send a signal (if
>>> cancellation is in asynchronous mode, this happens when the target
>>> thread is blocked inside a blocking call). But this should not be a
>>> problem with RPI.
>> I disabled priority coupling in the kernel and it did not help or harm.
>> This test uses PTHREAD_CANCEL_DEFERRED, which is  also the default, if
>> I understood correctly.
> 
> You should definitely enable priority coupling. Even if you use
> PTHREAD_CANCEL_DEFERRED, when you call a blocking call, the cancellation
> is switched for the time of the blocking call to asynchronous. But since
> you do not call any blocking call, I agree that pthread_cancel should
> not switch to secondary mode, it should just set a bit in some TCB
> attached to the target thread.
> 
>>> But the problem you should focus on is why the scheduler does not let
>>> pthread_cancel run earlier.
>> Don't know what you mean. The calc_func gets preempted and the ctrl_func
>> calls pthread_cancel as expected...
>>
>>   calc_func: at count 20
>>   calc_func: at count 21
>>   calc_func: at count 22
>>   ctrl_func: cancel at count 23
>>   ^^^^^^^^^
>>   calc_func: at count 23
>>
>> But then it stops somehow in pthread_cancel and calc_func continues to run.
> 
> Yes, but since "ctrl_func: stopped at count 23" does not appear, it
> means that ctrl_func is somehow blocked in pthread_cancel.
> 
> Does the test work if calc_func calls nanosleep instead of
> create_load_100ms ?

Yes.

I'm getting closer now, I think, I hope. pthread_cancel seems only to
work if calc_thread runs in secondary mode. If I set policy and priority
at the beginning of the thread function, nor pthread_setschedparam nor
clock_gettime switches to primary mode and therefore calc_thread runs in
secondary mode. If I add explicit
pthread_set_mode_np(0, PTHREAD_PRIMARY), pthread_cancel is not able to
terminate the calc_thread anymore, even with pthread_testcancel.

Wolfgang.