How to force re-evaluate thread_local address?

Project Infrastructure LLVM Dev List Archives
1

Hi everyone,

I’m working on adding multithreading support to our programming language (http://crystal-lang.org) and I’m facing an issue with thread local variables.
Since the language relies heavily on coroutines, basically the problem is that a function could start running on a thread, get suspended and continue running on a different thread.

So, for example, if I have this pseudocoe:

  1. read / write thread local variable
  2. do some context switch, might resume in a different thread
  3. read / write same thread local variable

Now the real issue is that when compiling with optimizations, LLVM wont re-read the thread local address, and instead it will rely on the address stored on some register.

The question is: is there any way to force LLVM to re-read the thread local address each time? Or even better, is there any way to give hints about where the cached address is not reliable anymore?

Best regards!

  • Juan
2

IIRC, this is a long-standing issue and some of our game teams that use coroutine-like job systems run into this as well. My recollection is that it is a big pile of work to fix this in the llvm backend. The workaround is to do all thread-local access via functions that access thread-local state and do not do any context-switching (and these functions must not be inlined, obviously).

– Sean Silva

3

Correct. This is pr19177.

Cheers,
Rafael