On Dec 10, 2007 4:20 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> 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 <[EMAIL 
> > PROTECTED]> wrote:
> >  > >  >  > >> Gilles Chanteperdrix wrote:
> >  > >  >  > >>> On Dec 6, 2007 2:28 PM, Gilles Chanteperdrix
> >  > >  >  > >>> <[EMAIL PROTECTED]> wrote:
> >  > >  >  > >>>> On Dec 6, 2007 2:24 PM, Wolfgang Grandegger <[EMAIL 
> > PROTECTED]> wrote:
> >  > >  >  > >>>>> Gilles Chanteperdrix wrote:
> >  > >  >  > >>>>>> On Dec 6, 2007 1:31 PM, Wolfgang Grandegger <[EMAIL 
> > PROTECTED]> 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.

>
> The low_prio_task() seems to be aborted and the process is stopped. If I
> do a "kill %1" though, the system hangs. I'm now trying Xenomai trunk
> with Linux 2.6.23.

That is expected: you installed a handler for SIGTERM which does not
call exit or do not call anything which will end the application. So,
sending SIGTERM simply unblocks all thread, and the low priority
thread, now running in secondary mode, blocks the CPU. If you enable
Linux soft lockup detector, you will see a warning on the console.

IMHO, a handler for SIGTERM should reinstall the default signal
handler, and raise the SIGTERM signal anew. In other words, you should
add at the end of the sighand function:
signal(sig, SIG_DFL);
raise(sig);

>
> Wolfgang.
>
>



-- 
                                               Gilles Chanteperdrix

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to