2015-09-05 22:04 GMT+02:00 Hartmut Kaiser <hartmut.kaiser@gmail.com>:
>> 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)