2015-09-05 22:04 GMT+02:00 Hartmut Kaiser
a) is safe as all threads sharing the same scheduler store the same reference (fibers can be moved only inside that scheduler) b) is safe as the runtime sets the reference to the fiber it is about to run in TLS and resets it right after the fiber returned.
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.
hmm, that's strange because I got those problems as I implemented support for migrating fibers. after optimization the code form the example looks like this: void bar( Fiber * f) { printf("%p\n", f);; suspend_and_migrate(); } void foo() { Fiber * f = return_ptr_to_active_fiber(); while( true) { bar( f); } } the code is translated back from assembler (g++ -S -std=c++11 -O1 test_tls.cpp)