* [Xenomai-help] pthread exit and PTHREAD_WARNSW
@ 2011-04-12 14:27 Jeff Weber
2011-04-12 14:38 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Weber @ 2011-04-12 14:27 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
>From testing, I found that if I enable PTHREAD_WARNSW for a pthread, I must
explicitly disable this mode before the thread terminates, or the thread
draws a signal 24 SIGXCPU.
I've tried to simplify my thread terminations by pushing a function which
calls pthread_set_mode_np(PTHREAD_WARNSW, 0) onto the thread cleanup stack,
and always terminating the thread via pthread_exit(). However, this method
still draws a signal 24 SIGXCPU. Here's a sample backtrace:
Program terminated with signal 24, CPU time limit exceeded.
#0 0xffffe424 in __kernel_vsyscall ()
(gdb) bt full
#0 0xffffe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb781d561 in pthread_once () from /lib/libpthread.so.0
No symbol table info available.
#2 0xb76e0450 in ?? () from /lib/libgcc_s.so.1
No symbol table info available.
#3 0xb76e09de in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1
No symbol table info available.
#4 0xb7821032 in _Unwind_ForcedUnwind () from /lib/libpthread.so.0
No symbol table info available.
#5 0xb781ea97 in __pthread_unwind () from /lib/libpthread.so.0
No symbol table info available.
#6 0xb7818a5e in pthread_exit () from /lib/libpthread.so.0
No symbol table info available.
#7 0x0804969b in my program termination code
Am I coding this incorrectly, or is this just the way pthreads interacts
with Xenomai?
my config:
# xeno-config --version
2.5.6
# ldd ./mq_test
linux-gate.so.1 => (0xffffe000)
libpthread_rt.so.1 => /usr/xenomai/lib/libpthread_rt.so.1
(0xb778b000)
libxenomai.so.0 => /usr/xenomai/lib/libxenomai.so.0 (0xb7785000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb776a000)
librt.so.1 => /lib/librt.so.1 (0xb7760000)
librtdk.so.0 => /usr/xenomai/lib/librtdk.so.0 (0xb775a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb766a000)
libm.so.6 => /lib/libm.so.6 (0xb7640000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7622000)
libc.so.6 => /lib/libc.so.6 (0xb74b7000)
/lib/ld-linux.so.2 (0xb77b4000)
#> rpm -qf /lib/libpthread.so.0
glibc-2.11.2-3.1.1.i686
# uname -a
Linux xeno2 2.6.37.3-xeno-2.5.6-smp #1 SMP PREEMPT Fri Mar 11 12:43:02 CST
2011 i686 i686 i386 GNU/Linux
TIA,
Jeff
[-- Attachment #2: Type: text/html, Size: 2809 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-help] pthread exit and PTHREAD_WARNSW 2011-04-12 14:27 [Xenomai-help] pthread exit and PTHREAD_WARNSW Jeff Weber @ 2011-04-12 14:38 ` Gilles Chanteperdrix 2011-04-12 15:06 ` Jeff Weber 0 siblings, 1 reply; 6+ messages in thread From: Gilles Chanteperdrix @ 2011-04-12 14:38 UTC (permalink / raw) To: Jeff Weber; +Cc: xenomai Jeff Weber wrote: Hi Jeff, any news about the hostrt patch I sent you for x86_32? Does it work? > From testing, I found that if I enable PTHREAD_WARNSW for a pthread, I must > explicitly disable this mode before the thread terminates, or the thread > draws a signal 24 SIGXCPU. Yes, the problem is that we can put such migration if the thread function returns, but it will not work in case pthread_exit is called. > > I've tried to simplify my thread terminations by pushing a function which > calls pthread_set_mode_np(PTHREAD_WARNSW, 0) onto the thread cleanup stack, > and always terminating the thread via pthread_exit(). However, this method > still draws a signal 24 SIGXCPU. Here's a sample backtrace: ... and pthread_exit is basically a Linux service, so, we can not guarantee that it does not make any syscall before executing the cleanup handlers. -- Gilles. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] pthread exit and PTHREAD_WARNSW 2011-04-12 14:38 ` Gilles Chanteperdrix @ 2011-04-12 15:06 ` Jeff Weber 2011-04-12 15:20 ` Gilles Chanteperdrix 0 siblings, 1 reply; 6+ messages in thread From: Jeff Weber @ 2011-04-12 15:06 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai [-- Attachment #1: Type: text/plain, Size: 1692 bytes --] Gilles: On Tue, Apr 12, 2011 at 9:38 AM, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org> wrote: > Jeff Weber wrote: > > Hi Jeff, > > any news about the hostrt patch I sent you for x86_32? Does it work? > Yes it works. However my call to clock_gettime(CLOCK_HOST_REALTIME) takes too long (110 nsec on my CPU) for my ISR, so I will read the TSC instead, and convert the TSC to host time in another thread. Thanks for your help though. > > > From testing, I found that if I enable PTHREAD_WARNSW for a pthread, I > must > > explicitly disable this mode before the thread terminates, or the thread > > draws a signal 24 SIGXCPU. > > Yes, the problem is that we can put such migration if the thread > function returns, but it will not work in case pthread_exit is called. > I'm interested if there is a way to automatically disable PTHREAD_WARNSW as threads terminate, using return from the entry function. I was only using pthread_exit() to leverage the thread cleanup stack capability, and queue a call to pthread_set_mode_np(PTHREAD_WARNSW, 0) . > > > > > I've tried to simplify my thread terminations by pushing a function which > > calls pthread_set_mode_np(PTHREAD_WARNSW, 0) onto the thread cleanup > stack, > > and always terminating the thread via pthread_exit(). However, this > method > > still draws a signal 24 SIGXCPU. Here's a sample backtrace: > > ... and pthread_exit is basically a Linux service, so, we can not > guarantee that it does not make any syscall before executing the cleanup > handlers. > Right, I saw there was no __wrap_pthread_exit in /usr/xenomai/lib/libpthread_rt.so Jeff > > -- > Gilles. > [-- Attachment #2: Type: text/html, Size: 2572 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] pthread exit and PTHREAD_WARNSW 2011-04-12 15:06 ` Jeff Weber @ 2011-04-12 15:20 ` Gilles Chanteperdrix 2011-04-12 18:39 ` Jeff Weber 0 siblings, 1 reply; 6+ messages in thread From: Gilles Chanteperdrix @ 2011-04-12 15:20 UTC (permalink / raw) To: Jeff Weber; +Cc: xenomai Jeff Weber wrote: > Gilles: > > On Tue, Apr 12, 2011 at 9:38 AM, Gilles Chanteperdrix < > gilles.chanteperdrix@xenomai.org> wrote: > >> Jeff Weber wrote: >> >> Hi Jeff, >> >> any news about the hostrt patch I sent you for x86_32? Does it work? >> > > Yes it works. However my call to clock_gettime(CLOCK_HOST_REALTIME) takes > too long (110 nsec on my CPU) for my ISR, so I will read the TSC instead, > and convert the TSC to host time in another thread. Thanks for your help > though. Wow, it makes me wonder what kind of ISR with a multi-us latency can not handle a 110ns service. But I admit that the hostrt clock_gettime service is a bit heavy. I am afraid there is not much we can do. Could you get me disassembly of the kernel-space clock.o file, so that I verify that we do not end up using divisions? For instance clock_gettime(CLOCK_MONOTONIC) is wrong, and uses the real division. > > >>> From testing, I found that if I enable PTHREAD_WARNSW for a pthread, I >> must >>> explicitly disable this mode before the thread terminates, or the thread >>> draws a signal 24 SIGXCPU. >> Yes, the problem is that we can put such migration if the thread >> function returns, but it will not work in case pthread_exit is called. >> > > I'm interested if there is a way to automatically disable PTHREAD_WARNSW as > threads terminate, using return from the entry function. I was only using > pthread_exit() to leverage the thread cleanup stack capability, and queue a > call to pthread_set_mode_np(PTHREAD_WARNSW, 0) . You can do that in the trampoline in src/skins/posix/thread.c, right after the call to entry(cookie). I will send a patch tonight if you prefer. > >>> I've tried to simplify my thread terminations by pushing a function which >>> calls pthread_set_mode_np(PTHREAD_WARNSW, 0) onto the thread cleanup >> stack, >>> and always terminating the thread via pthread_exit(). However, this >> method >>> still draws a signal 24 SIGXCPU. Here's a sample backtrace: >> ... and pthread_exit is basically a Linux service, so, we can not >> guarantee that it does not make any syscall before executing the cleanup >> handlers. >> > > Right, I saw there was no __wrap_pthread_exit > in /usr/xenomai/lib/libpthread_rt.so That is something else we can do, add a __wrap_pthread_exit which removes the bit before calling __read_pthread_exit. Neither of the two methods will work for pthread_cancel though. > > Jeff > >> -- >> Gilles. >> > -- Gilles. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] pthread exit and PTHREAD_WARNSW 2011-04-12 15:20 ` Gilles Chanteperdrix @ 2011-04-12 18:39 ` Jeff Weber 2011-04-14 12:15 ` Gilles Chanteperdrix 0 siblings, 1 reply; 6+ messages in thread From: Jeff Weber @ 2011-04-12 18:39 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai [-- Attachment #1.1: Type: text/plain, Size: 2136 bytes --] On Tue, Apr 12, 2011 at 10:20 AM, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org> wrote: > Jeff Weber wrote: > > Gilles: > > > > On Tue, Apr 12, 2011 at 9:38 AM, Gilles Chanteperdrix < > > gilles.chanteperdrix@xenomai.org> wrote: > > > >> Jeff Weber wrote: > >> > >> Hi Jeff, > >> > >> any news about the hostrt patch I sent you for x86_32? Does it work? > >> > > > > Yes it works. However my call to clock_gettime(CLOCK_HOST_REALTIME) > takes > > too long (110 nsec on my CPU) for my ISR, so I will read the TSC instead, > > and convert the TSC to host time in another thread. Thanks for your help > > though. > > Wow, it makes me wonder what kind of ISR with a multi-us latency can not > handle a 110ns service. But I admit that the hostrt clock_gettime > service is a bit heavy. I am afraid there is not much we can do. Could > you get me disassembly of the kernel-space clock.o file, so that I > verify that we do not end up using divisions? For instance > clock_gettime(CLOCK_MONOTONIC) is wrong, and uses the real division. > See attached. Let me know if attachment gets stripped off along the way. > > > > > > >>> From testing, I found that if I enable PTHREAD_WARNSW for a pthread, I > >> must > >>> explicitly disable this mode before the thread terminates, or the > thread > >>> draws a signal 24 SIGXCPU. > >> Yes, the problem is that we can put such migration if the thread > >> function returns, but it will not work in case pthread_exit is called. > >> > > > > I'm interested if there is a way to automatically disable PTHREAD_WARNSW > as > > threads terminate, using return from the entry function. I was only > using > > pthread_exit() to leverage the thread cleanup stack capability, and queue > a > > call to pthread_set_mode_np(PTHREAD_WARNSW, 0) . > > You can do that in the trampoline in src/skins/posix/thread.c, right > after the call to entry(cookie). I will send a patch tonight if you prefer. > Yes, a patch would be appreciated at your earliest convenience. No need to rush it tonight. Do you consider this a candidate for released code, or should I consider this a 1-off? > > thanks, Jeff [-- Attachment #1.2: Type: text/html, Size: 3054 bytes --] [-- Attachment #2: clock.lst.gz --] [-- Type: application/x-gzip, Size: 17343 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] pthread exit and PTHREAD_WARNSW 2011-04-12 18:39 ` Jeff Weber @ 2011-04-14 12:15 ` Gilles Chanteperdrix 0 siblings, 0 replies; 6+ messages in thread From: Gilles Chanteperdrix @ 2011-04-14 12:15 UTC (permalink / raw) To: Jeff Weber; +Cc: xenomai Jeff Weber wrote: > On Tue, Apr 12, 2011 at 10:20 AM, Gilles Chanteperdrix < > gilles.chanteperdrix@xenomai.org> wrote: > >> Jeff Weber wrote: >>> Gilles: >>> >>> On Tue, Apr 12, 2011 at 9:38 AM, Gilles Chanteperdrix < >>> gilles.chanteperdrix@xenomai.org> wrote: >>> >>>> Jeff Weber wrote: >>>> >>>> Hi Jeff, >>>> >>>> any news about the hostrt patch I sent you for x86_32? Does it work? >>>> >>> Yes it works. However my call to clock_gettime(CLOCK_HOST_REALTIME) >> takes >>> too long (110 nsec on my CPU) for my ISR, so I will read the TSC instead, >>> and convert the TSC to host time in another thread. Thanks for your help >>> though. >> Wow, it makes me wonder what kind of ISR with a multi-us latency can not >> handle a 110ns service. But I admit that the hostrt clock_gettime >> service is a bit heavy. I am afraid there is not much we can do. Could >> you get me disassembly of the kernel-space clock.o file, so that I >> verify that we do not end up using divisions? For instance >> clock_gettime(CLOCK_MONOTONIC) is wrong, and uses the real division. >> > > See attached. Let me know if attachment gets stripped off along the way. > >>> >>>>> From testing, I found that if I enable PTHREAD_WARNSW for a pthread, I >>>> must >>>>> explicitly disable this mode before the thread terminates, or the >> thread >>>>> draws a signal 24 SIGXCPU. >>>> Yes, the problem is that we can put such migration if the thread >>>> function returns, but it will not work in case pthread_exit is called. >>>> >>> I'm interested if there is a way to automatically disable PTHREAD_WARNSW >> as >>> threads terminate, using return from the entry function. I was only >> using >>> pthread_exit() to leverage the thread cleanup stack capability, and queue >> a >>> call to pthread_set_mode_np(PTHREAD_WARNSW, 0) . >> You can do that in the trampoline in src/skins/posix/thread.c, right >> after the call to entry(cookie). I will send a patch tonight if you prefer. >> > > Yes, a patch would be appreciated at your earliest convenience. No need to > rush it tonight. Do you consider this a candidate for released code, or > should I consider this a 1-off? Ok. Here it comes. Sorry for the delay. diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c index 109650c..c913ac4 100644 --- a/src/skins/posix/thread.c +++ b/src/skins/posix/thread.c @@ -235,6 +235,7 @@ static void *__pthread_trampoline(void *arg) if (policy != SCHED_OTHER) XENOMAI_SYSCALL1(__xn_sys_migrate, XENOMAI_XENO_DOMAIN); status = start(cookie); + XENOMAI_SYSCALL1(__xn_sys_migrate, XENOMAI_LINUX_DOMAIN); } else status = (void *)-err; Since it does not fix the issue completely, I am not sure it is the right solution. I guess doing something in kernel-space would be better. -- Gilles. ^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-04-14 12:15 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-12 14:27 [Xenomai-help] pthread exit and PTHREAD_WARNSW Jeff Weber 2011-04-12 14:38 ` Gilles Chanteperdrix 2011-04-12 15:06 ` Jeff Weber 2011-04-12 15:20 ` Gilles Chanteperdrix 2011-04-12 18:39 ` Jeff Weber 2011-04-14 12:15 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.