Reid raised this issue in a bug comment that I thought should be discussed on the mailing list:
http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=540
I'm really not sure this is wise unless there is consensus that lli should always be a multi-threaded program. Certainly, there's enough problems with multi-threading that this could break many tests. I'd like some other folks to chime in on this before we make this change.
In order for LLVM to execute programs that are multithreaded, the JIT must be thread-safe. I am not aware of anyway of doing this "selectively." My patch (http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=418) adds a lock to ExecutionEngine.h, which means that the JIT must *always* be thread-safe, which means that it must always be linked against a platform's thread library.
So the question is: Should the JIT always have locks, and always be thread-safe? This question really means "should LLVM always be capable of executing multithreaded programs?"
Evan Jones
On a related note, I've updated my patch to fix the bug that I found in it, and I discussed on the mailing list last month. The details can be found in the bug:
http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=418
This is definitely *not* something that should go in before 1.5 is released, but I would love to see it integrated shortly after.
Evan Jones
Now that 1.5 has been released, would it be possible to have some discussion about if linking the JIT with a thread library is the direction that should be taken? I don't see any alternative except having separate "threaded" and "unthreaded" JITs, and requiring the user to know when the different JITs should be used.
Thanks,
Evan Jones
I think that this is fine.
-Chris
Does that mean option 1 or option 2 is fine:
1. Always link the JIT against a platform's thread library so it is always thread-safe.
2. Build two JITs, one that is thread-safe, and another which is not. Users must manually select the correct JIT.
Evan Jones
Now that 1.5 has been released, would it be possible to have some discussion about if linking the JIT with a thread library is the direction that should be taken? I don't see any alternative except having separate "threaded" and "unthreaded" JITs, and requiring the user to know when the different JITs should be used.
I think that this is fine.
Does that mean option 1 or option 2 is fine:
1. Always link the JIT against a platform's thread library so it is always thread-safe.
I would prefer this option. Ideally the thread model would be selectable by the specific tool that links to the JIT (to support user-level thread libraries and stuff), but that should be left to a later enhancement.
-Chris
2. Build two JITs, one that is thread-safe, and another which is not. Users must manually select the correct JIT.
Evan Jones
--
Evan Jones
http://evanjones.ca/
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-Chris