2015-09-05 22:04 GMT+02:00 Hartmut Kaiser
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.