[Bug middle-end/26461] liveness of thread local references across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461 John Ousterhout changed: What|Removed |Added CC||ouster at cs dot stanford.edu --- Comment #13 from John Ousterhout --- Kernel threads are great, and it may seem like there's no need for user-level threads now that kernel threads are universally available. But layering user-level threads on top of kernel threads can offer a speedup of at least 10x for common operations. The fact that so many different people have responded on this issue and issue 26461 is pretty good evidence that it can be useful to do "context switching" on top of kernel threads. My research group has recently run up against this same problem. Thread-local variables (i.e. kernel-thread-locals) are still useful in this environment (for example, we use one to keep track of the user thread that's loaded on the current kernel thread). One of the great things about gcc is that it has supported a huge variety of applications and design styles; it would be a shame for gcc to preclude this particular class of applications. Is it unreasonably difficult to add a mechanism to force gcc to flush cached thread-local addresses? Those of us using the mechanism would be happy to pay a small performance penalty for it, but presumably that won't affect applications that don't use the mechanism. Please reconsider?
[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80258 John Ousterhout changed: What|Removed |Added CC||ouster at cs dot stanford.edu --- Comment #10 from John Ousterhout --- I accidentally posted this on issue 26461, so I'm reposting here; sorry for the duplicate... Kernel threads are great, and it may seem like there's no need for user-level threads now that kernel threads are universally available. But layering user-level threads on top of kernel threads can offer a speedup of at least 10x for common operations. The fact that so many different people have responded on this issue and issue 26461 is pretty good evidence that it can be useful to do "context switching" on top of kernel threads. My research group has recently run up against this same problem. Thread-local variables (i.e. kernel-thread-locals) are still useful in this environment (for example, we use one to keep track of the user thread that's loaded on the current kernel thread). One of the great things about gcc is that it has supported a huge variety of applications and design styles; it would be a shame for gcc to preclude this particular class of applications. Is it unreasonably difficult to add a mechanism to force gcc to flush cached thread-local addresses? Those of us using the mechanism would be happy to pay a small performance penalty for it, but presumably that won't affect applications that don't use the mechanism. Please reconsider?
