* [email protected] ([email protected]) wrote:
>
>
> On 04 May, 2011,at 06:31 AM, Mathieu Desnoyers <[email protected]>
> wrote:
>
> We use the pthread primitives for mutexes, thread creation, and rely on
> the TLS provided by gcc. Can you elaborate more on the limitations the
> Android target has with respect to pthread and TLS support ?
>
> The biggest obstacle is that gcc's __thread specifier isn't supported on
> Android.
>
> Currently, the only alternative seems to be the pthread_{get,set}specific()
> API,
> see http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_setspecific.html
>
> The difference between the approaches is that with POSIX TLS we will have to
> dynamically obtain a pointer to the thread local rcu_reader rather than
> thread local struct. (See code below)
>
> static inline void _rcu_read_lock(void) {
> unsigned long tmp;
> cmm_barrier(); /* Ensure the compiler does not reorder us with mutex */
> #ifdef USE_POSIX_TLS
> struct rcu_reader *rcu_reader = thread_local_rcu_reader();
> tmp = rcu_reader->ctr;
Yep, that should work fine where __thread is not implemented.
> if (likely(!(tmp & RCU_GP_CTR_NEST_MASK))) {
> _CMM_STORE_SHARED(rcu_reader->ctr,
> _CMM_LOAD_SHARED(rcu_gp_ctr));
> smp_mb_slave(RCU_MB_GROUP);
> } else {
> _CMM_STORE_SHARED(rcu_reader->ctr, tmp + RCU_GP_COUNT);
> }
> #else
> tmp = rcu_reader.ctr;
> if (likely(!(tmp & RCU_GP_CTR_NEST_MASK))) {
> _CMM_STORE_SHARED(rcu_reader.ctr, _CMM_LOAD_SHARED(rcu_gp_ctr));
> smp_mb_slave(RCU_MB_GROUP);
> } else {
> _CMM_STORE_SHARED(rcu_reader.ctr, tmp + RCU_GP_COUNT);
> }
> #endif
> }
>
> What worries me a bit is the macro
> CMM_ACCESS_ONCE (inside _CMM_STORE_SHARED) that I have yet to grok.
CMM_ACCESS_ONCE is really just a cast through a volatile, to make sure
the compiler consider the data to store (or load) as being stored
(loaded) into (from) a volatile container. Nothing more, really. You
might want to refer to the Linux kernel comment above ACCESS_ONCE() to
see why it is needed.
Thanks,
Mathieu
>
> /Per
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
