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

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

Jan Kiszka wrote:
> 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).

The trouble is to make some reliable detections in the configure script,
so that the user will know early that Xenomai can not work with its
current toolchain. And to make this detection work with uclibc as well
as with glibc, gcc 4 versus gcc 3, etc...

Besides, pthread_getspecific can be implemented pretty efficiently in
user-space without __thread support: using a hash table would be enough.
 So, if we rely on pthread_getspecific, we do not have to know if ptd
are implemented with some hardware trick.

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

I would say the __thread variable is used to store an array, which is,
according to what Philippe said yesterday, turned into a multilevel
structure when creating more than 32 keys.

At the hardware level, I am pretty sure ARM has only one per thread
token. However I do not know how it is used to implement __thread
variable (or variables).

-- 
                                                 Gilles.