Re: [Xenomai-core] How to cancel a Xenomai POSIX thread

[Wolfgang Grandegger <wg@domain.hid>]

Gilles Chanteperdrix wrote:
> On Dec 10, 2007 4:20 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Grandegger wrote:
>>>  > Gilles Chanteperdrix wrote:
>>>  > > Gilles Chanteperdrix wrote:
>>>  > >  > Wolfgang Grandegger wrote:
>>>  > >  >  > Hi Gilles,
>>>  > >  >  >
>>>  > >  >  > Gilles Chanteperdrix wrote:
>>>  > >  >  > > On Dec 6, 2007 3:05 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>>>  > >  >  > >> Gilles Chanteperdrix wrote:
>>>  > >  >  > >>> On Dec 6, 2007 2:28 PM, Gilles Chanteperdrix
>>>  > >  >  > >>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>  > >  >  > >>>> On Dec 6, 2007 2:24 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>>>  > >  >  > >>>>> Gilles Chanteperdrix wrote:
>>>  > >  >  > >>>>>> On Dec 6, 2007 1:31 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
>>>  > >  >  > >>>>>>> Hello,
>>>  > >  >  > >>>>>>>
>>>  > >  >  > >>>>>>> how do I cancel or delete a Xenomai POSIX thread running in primary
>>>  > >  >  > >>>>>>> context from a higher priority thread? IIUC, pthread_kill() can only be
>>>  > >  >  > >>>>>>> used in secondary context. I tried pthread_cancel(), but it only works
>>>  > >  >  > >>>>>>> when hitting a cancelation point, e.g. pthread_testcancel(). Setting
>>>  > >  >  > >>>>>>> pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS) did not help. Is
>>>  > >  >  > >>>>>>> there a code snippet or even an example program showing how to cancel a
>>>  > >  >  > >>>>>>> pthread in primary context?
>>>  > >  >  > >>>>>> pthread_kill or pthread_cancel should result in sending a signal to
>>>  > >  >  > >>>>>> the target thread, so should cause this thread to switch to secondary
>>>  > >  >  > >>>>>> mode to handle it. If you want to wait for the target thread to be
>>>  > >  >  > >>>>>> canceled, you should use pthread_cancel and pthread_join.
>>>  > >  >  > >>>>> There is no way to cancel a pthread in primary mode from another pthread?
>>>  > >  >  > >>>> No. You always need secondary mode to effectively delete a thread. The
>>>  > >  >  > >>>> same goes for the native skin.
>>>  > >  >  > >>> Ok. I understand what you mean. You want pthread_cancel not to leave
>>>  > >  >  > >>> primary mode. This can easily be done by causing pthread_cancel to use
>>>  > >  >  > >>> the kernel-space real-time pthread_cancel service. This should work
>>>  > >  >  > >>> with no further modification.
>>>  > >  >  > >> I want to cancel/delete a task running in primary mode, e.g.
>>>  > >  >  > >>
>>>  > >  >  > >>   void* work_task(void* dummy)
>>>  > >  >  > >>   {
>>>  > >  >  > >>         int count = 0;
>>>  > >  >  > >>         while (1)
>>>  > >  >  > >>                 count++;
>>>  > >  >  > >>   }
>>>  > >  >  > >>
>>>  > >  >  > >> from the outside (= another higher priority task). How can I use the
>>>  > >  >  > >> kernel-space real-time pthread_cancel service? My POSIX app is runs in
>>>  > >  >  > >> user-land.
>>>  > >  >  > >
>>>  > >  >  > > I was thinking about adding a pthread_cancel syscall that would have
>>>  > >  >  > > triggered the kernel-space pthread_cancel. But this will not work:
>>>  > >  >  > > user-space cleanup handlers would no longer get executed. However,
>>>  > >  >  > > this can work for pthread_kill. Here is a patch which adds the
>>>  > >  >  > > pthread_kill syscall.
>>>  > >  >  >
>>>  > >  >  > Great, thanks a lot. This seems to work but I'm now fiddling with proper
>>>  > >  >  > cleanup and exit. I have attached my small test program. It behaves
>>>  > >  >  > somehow strange, at least to me:
>>>  > >  >  >
>>>  > >  >  > - I see task period overruns when the low prio task is started. I
>>>  > >  >  >   suspect some switch to secondary mode in init_task().
>>>  > >  >  >
>>>  > >  >  > - The program/system hangs after the listed messages:
>>>  > >  >  >
>>>  > >  >  >   # ./kill_pthread
>>>  > >  >  >   Starting high_prio_task
>>>  > >  >  >   Killed low_prio task: count=3813129, overruns=0
>>>  > >  >  >
>>>  > >  >  > Any idea what I'm doing wrong?
>>>  > >  >  >
>>>  > >  >  > This is with Linux 2.4.25 and Xenomai 2.3.x on a MPC5200 board.
>>>  > >  >
>>>  > >  > Your test runs fine with Xenomai trunk (on ARM). I will now try with
>>>  > >  > current state of the v2.3.x branch.
>>>  > >
>>>  > > Works with v2.3.x too.
>>>  >
>>>  > I re-activated my test PC running Linux 2.6.20.21. with Xenomai 2.3.x.
>>>  > There the program runs fine _without_ your pthread_kill patch. For some
>>>  > reason the low_prio_task() is running in secondary mode (do you know
>>>  > why? Is there a function to check the mode?). I added
>>>  >
>>>  >         struct sched_param  param = { .sched_priority = LOW_PRIO };
>>>  >         pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);
>> After adding pthread_getschedparam() I realized, that policy was 1 and
>> prio 10 and not as expected 5. The corresponding attribute settings
>> before calling pthread_create have been ignored somehow. Am I doing
>> something wrong in task_init()?
>>
>>>  > to the head of that function and then I get:
>>>  >
>>>  >   ./kill_pthread
>>>  >   Starting high_prio_task
>>>  >   BUG: NMI Watchdog detected LOCKUP
>>>  >   Killed low_prio task: count=1588495996, overruns=0
>>>  >   Exiting main
>>>  >
>>>  > I have attached the corresponding oops in case it's of interest.
>>>  > Unfortunately, with your patch and adding the function
>>>  > __real_pthread_kill() to wrappers.c, the behavior is the same. I'm going
>>>  > to repeat the tests with Xenomai trunk tomorrow.
>>>
>>> The oops is due to the NMI watchdog calling some linux domain functions
>>> over Xenomai domain. You should probably use Xenomai watchdog instead.
>>>
>>> As for the reason why the watchdog triggers: are you sure you are
>>> running the kernel recompiled after having applied the patch?
>> Indeed, after a "make clean; make bzImage" of the kernel it behaves
>> differently. Wired, may be some dependency issue.
>>
>>   # ./kill_pthread
>>   Starting high_prio_task
>>   low_prio_task: policy=1 prio=10
>>   Killed low_prio task: count=172709970, overruns=0
>>
>>   [1]+  Stopped                 ./kill_pthread
> 
> What you are observing is probably a difference between linuxthreads
> and NPTL: with linuxthreads, SIGSTOP can be sent to a particular
> thread and will cause this thread only to stop. With NPTL, it seems
> that the effect of SIGSTOP is global, it affects the entire process. I
> will test tonight on my x86 box to see if I observe the same effect.

Ah, the man page says:

 Note  that  pthread_kill()  only causes the signal to be handled in the
 context of the given thread; the signal action  (termination  or  stop-
 ping) affects the process as a whole.

Wolfgang.