gnzlbg
commented
8 years ago So I just checked and in C++'s Coroutines Technical Specification reading a thread_local from a coroutine returns the value that the thread_local has on the thread currently running the coroutine. It is defined behavior.
And no, thread_local variables are not volatile. What happens is the following.
You initiate the coroutine on a particular thread. The coroutine runs on that thread until its first suspension point. Then it gets suspended.
When you resume the coroutine (in whatever thread you decide to do so), resuming the coroutine is just a function call that calls the system scheduler. The system scheduler then "possibly" migrates the coroutine to a different thread, which resumes the coroutine by calling a function that continues after the suspension point of the coroutine. When the coroutine after this point reads a thread_local variable, it reads the variable from the current thread running the coroutine (in C++ that value might not be initialized in that thread, so doing so might introduce undefined behavior due to a read of uninitialized memory, but not due to a read of a thread_local variable per se).
For this to work the compiler only needs to avoid caching / reordering reads of thread_local variables across suspension points in a coroutin, volatile is not needed. C++ coroutines are actually implemented as state machines internally.
zonyitoo
pcwalton
lhecker
Manishearth
steveklabnik
The issue
thread_local!is used in the stdlib, which does not work well with Coroutines. Repeated access to a TLS variable inside a method might be cached and optimized by LLVM. If a coroutine is transferred from one thread to another this can lead to problems, due to a coroutine still using the cached reference to the TLS storage from the previous thread.What is not the issue
TLS being incompatible with coroutines for the most part (e.g. here) is well known and not an issue per se. You want to use
rand::thread_rng()with coroutines? Just userand::StdRng::new()instead! Most of the time it's just quite easy to circumvent the TLS by simply using something different. This is not true for the stdlib though. One way or the other you're using it somewhere probably.Possible solutions
thread_local!. I think that this could be hard to achieve in a performant way though.PANIC_COUNTand it's wonky implementation and still make entirely sure that a stack is unwound twice. Other uses of TLS inside the stdlib could be wrapped insideinline(never)without causing large overheads.I hope we can find a solution for this as this is really a huge problem for using stackful coroutines with Rust and who doesn't want "Go" but with Rust's syntax, eh? :wink: