Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, to avoid deadlocks, we need to manually insert
GC.safepoint()
in non-allocating tasks and alsoyield
if multiple tasks are using low-level concurrency communication primitives such as atomics. I find it confusing thatyield()
does not implyGC.safepoint()
and so you have to write both. This is because my mental model ofyield
is to "letjulia
runtime do whatever it needs to do at the moment" and GC is a part ofjulia
runtime. Since it is possible to write non-allocating concurrent tasks, maybe it makes sense to invokeGC.safepoint()
at the locations that the programmers marking that it's OK to do context switch? Asyield()
is more than 100 times expensive thanGC.safepoint()
, I think the performance implication is negligible.More specifically, this patch adds a single unconditional safepoint in
jl_process_events
.MWE
An easy way to observe this is a very naive spin lock. (But this PR is not for advocating spin lock.)
Running this script with 2 threads prints
and hangs. That is to say,
yield
alone is not enough to trigger the safepoint. This patch fixes the deadlock.Benchmarking
yield
andGC.safepoint
Invoking them in (more or less) parallel does not change the rough estimate: