* [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.