Daniel Schnell wrote: > Philippe Gerum wrote: >> Use pthread_getspecific() for obtaining back a TLS data previously >> defined by pthread_setspecific(), indexed on a TLS key obtained from >> pthread_key_create(). Warning: AFAICT, only pthread_getspecific() >> refrain from performing any kind of Linux syscall (in the current >> NPTL and older LinuxThreads implementation, that is), thus won't >> migrate your RT task to secondary mode when called. The two others >> could call vanilla kernel services, so you must use them during >> non-critical preliminary init steps of your task. > > Does this mean that if you use pthread_getspecific() inside a user-space > application you will not switch to secondary mode ? I was just > abandoning using TLS because I could not imagine how the NPTL's > functionality can be done without a system call. Is this behaviour > something one can rely on in the future ?
AFAIK, the TLS ABIs for all relevant architectures are build upon mechanisms (typically registers, sometimes with further pointer walks) that avoid syscalls - already for performance reasons. The only thing I'm not sure of is if all implementations create TLS space during thread setup or on first access. But as you will likely fill in data during setup anyway, that should be no practical problem. > > Is there something similar like TLS inside the native API ? No need for it, at least in user-space. Use what glibc and the kernel provide to you. Specifically __thread variables are very handy and efficient. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
