You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
threading deadlock: change jl_fptr_wait_for_compiled to actually compile code (JuliaLang#56571)
The jl_fptr_wait_for_compiled state merely means it could compile that
code, but in many circumstances, it will not actually compile that code
until a long delay: when either all edges are satisfied or it is
demanded to run immediately. The previous logic did not handle that
possibility leading to deadlocks (possible even on one thread).
A high rate of failure was shown on running the following CI test:
$ ./julia -t 20 -q <<EOF
for i = 1:1000
i % 10 == 0 && @show i
(@eval function _atthreads_greedy_dynamic_schedule()
inc = Threads.Atomic{Int}(0)
Threads.@threads :greedy for _ = 1:Threads.threadpoolsize()
Threads.@threads :dynamic for _ = 1:Threads.threadpoolsize()
Threads.atomic_add!(inc, 1)
end
end
return inc[]
end)() == Threads.threadpoolsize() * Threads.threadpoolsize()
end
EOF
Copy file name to clipboardExpand all lines: src/jitlayers.cpp
+5-4Lines changed: 5 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -278,6 +278,7 @@ static int jl_analyze_workqueue(jl_code_instance_t *callee, jl_codegen_params_t
278
278
// But it must be consistent with the following invokenames lookup, which is protected by the engine_lock
279
279
uint8_t specsigflags;
280
280
void *fptr;
281
+
voidjl_read_codeinst_invoke(jl_code_instance_t *ci, uint8_t *specsigflags, jl_callptr_t *invoke, void **specptr, int waitcompile) JL_NOTSAFEPOINT; // not a safepoint (or deadlock) in this file due to 0 parameter
0 commit comments