<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks Lang, that’s the clearest answer I have heard about this question :)<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2021, at 14:22, Lang Hames <<a href="mailto:lhames@gmail.com" class="">lhames@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Mo,<div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I’m new to JIT and just started experiencing on some example code with ORCv2, but could not get my head around with the thread safety.</blockquote><div class=""><br class=""></div><div class="">The short version is that ThreadSafeContext is a pair of an LLVMContext and a mutex, and that mutex is locked whenever you call ThreadSafeModule::withModuleDo on a module using that ThreadSafeContext.</div><div class=""><br class=""></div><div class="">That means that two Modules that share a Context can't be accessed simultaneously (when wrapped in and accessed through ThreadSafeModule and ThreadSafeContext).</div><div class=""><div class=""><br class=""></div><div class="">In this system you rarely have to do anything explicitly. The idea is that you access the module via withModuleDo and that takes care of the locking for you.</div><br class="gmail-Apple-interchange-newline"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Scenario 1, Application has multiple threads and each thread spawns its own JIT instance, within each JIT instance, there are multiple ThreadSafeModules share one ThreadSafeContext<br class="">Do I have to lock TSM/ TSC?</blockquote><div class=""><br class=""></div><div class="">You should always use withModuleDo to access the module, regardless of your setup. This prevents you from writing non-thread-safe code that might be difficult to debug if you add threading in later. What's important here is knowing the locking implications of the access pattern, since they'll affect how much parallelism you can get out of your JIT.</div><div class=""><br class=""></div><div class="">In your Scenario 1 each thread accesses a single LLVMContext. There are no LLVMContexts shared between threads, so no chance for lock contention. That's good.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> Scenario 2, If JIT itself has multiple compilation threads, like via setting NumCompileThreads in LLJIT classes, and each ThreadSafeModule has its own ThreadSafeContext, so context is not shared</blockquote><div class=""><br class=""></div><div class="">In this scenario each JIT has multiple threads, but each thread is operating on a single module with its own LLVMContext. Again there is no chance for lock contention, so no barrier to parallelism.</div><div class=""><br class=""></div><div class="">The only scenario where locking becomes relevant is when you have multiple threads and a single ThreadSafeContext shared between two or more ThreadSafeModules. Consider a JIT with 10 threads and 10 llvm::Modules all sharing a single ThreadSafeContext. If you issue a lookup that triggers materialization of all 10 modules simultaneously then they'll be sent to each of your 10 worker threads to be compiled, but as soon as the 1st worker thread takes the context lock the other 9 threads will be blocked from progressing. Eventually the 1st worker thread will relinquish the lock and the next worker thread will take it, preventing the other 8 threads from progressing, and so on. You have 10 threads, but only one thread at a time can actually do any work -- the single LLVMContext has serialized compilation.</div><div class=""><br class=""></div><div class="">My recommendation is to always start with one context per module, and only share contexts if you see memory consumption from the contexts becoming an issue.</div><div class=""><br class=""></div><div class="">-- Lang.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 12:13 AM mo xiaoming via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi all,<br class="">
<br class="">
I’m new to JIT and just started experiencing on some example code with ORCv2, but could not get my head around with the thread safety.<br class="">
<br class="">
Scenario 1, Application has multiple threads and each thread spawns its own JIT instance, within each JIT instance, there are multiple ThreadSafeModules share one ThreadSafeContext<br class="">
<br class="">
Do I have to lock TSM/ TSC?<br class="">
<br class="">
Scenario 2, If JIT itself has multiple compilation threads, like via setting NumCompileThreads in LLJIT classes, and each ThreadSafeModule has its own ThreadSafeContext, so context is not shared<br class="">
<br class="">
In this case, do I have to lock? If so, what’s the granularity of each lock should be, anything before IR generation in one locking?<br class="">
<br class="">
<br class="">
I think in scenario 1, locking is not needed because of no concurrent access. And I believe locking is a mandatory in scenario 2, but I don’t know why...<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>