Re: [Xenomai-help] pthread exit and PTHREAD_WARNSW

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.