Re: [Xenomai-core] __thread instead of pthread_get/setspecific

[Jan Kiszka <jan.kiszka@domain.hid>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> looking into the "xeno_in_primary_mode" thing I wondered how to make the
>> thread state quickly retrievable. Going via pthread_getspecific as we do
>> for xeno_get_current appears logical - but not optimal. Though
>> getspecific is optimized for speed, it remains a function call, a few
>> sanity checks, and only finally a TLS variable access. That could be
>> achieved in a much lighter way by using a __thread variable.
>>
>> But can we assume that all target we support also support the __thread
>> storage class? TLS is surely mandatory now: I assume pthread_getspecific
>> would become non-RT safe without it, right? Is there anything we
>> can/must check for during configure to verify __thread support?
> 
> I really think that this optimization is not worth the trouble. Anyway,

As long as we cannot specify the amount of "trouble", it's hard to
decide. Me current feeling is that it should rather simplify the
implementation + save us quite a few ops in the fast path (even more
with upcoming thread-mode check).

> I have one question: is an implementation guaranteed to support more
> than one __thread variable? Because from ARM implementation I would say
> that ARM has only one __thread variable.

That would be weird - there is no such limitation known to me. Anyway,
you could easily verify this with a simple test program I guess. /me
also wonders how the glibc/NPTL is maintaining certain per-thread
variables (and there are surely > 1) internally.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux