2015-09-05 22:04 GMT+02:00 Hartmut Kaiser <hartmut.kaiser@gmail.com>:

> but I was asking for the code snipped which accesses TLS variable - if all
> threads share the same scheduler why has it to be stored in TLS?
> a slight modification of my example above - replace
> retrn_ptr_of_scheduler_thread_lcoal_var() by return_ptr_to_active_fiber()
> I assume that as you mentioned in b) that the active fiber is stored in
> TLS - the exmaple code prints out the address of the current active fiber
> how does the code look like after compiler optimization?

I don't know. We have never ran into any problems related to this.

I did a short look at the souces from HPX - please correct me if my assumptions are false:

- HPX does not support C++11, so thread_local is not available - instead you implemented thread_specific_ptr

- thread_specific_ptr has an private member - static __thread T * t - so thread_specific_ptr is the TLS container

- coroutine_impl has a private member - static thread_specific_ptr< self_type > self_ which is used to access the 'active fiber/coroutine' via
 static member function - static self_type * get_self()

- coroutine_impl::operator() executes the function/code passed to coroutine_impl

- the implementation of coroutine::operator() looks like this (in short):

void operator() {
   do {
     self_type * old_self = coroutine_impl::get_self();
     self_type self( this, old_self);
     reset_self_on_exit( & self, old_self);

     fun(); // execute function
   } while ( state == running);
}

I the compiler optimizes the code - self_type * old_self = coroutine_impl::get_self(); - will likely be moved out of the do-loop.

void operator() {
   self_type * old_self = coroutine_impl::get_self();
   do {
     self_type self( this, old_self);
     reset_self_on_exit( & self, old_self);

     fun(); // execute function
   } while ( state == running);
}

This happens probably in other places of HPX too - the question is why you never ran into any problems.