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
There was a discussion starting here: julep: a @select statement JuliaLang/julia#13763 (comment) that there is a race-condition for edge-triggered events in this implementation that can cause events to be dropped. We should consider whether it's possible to fix this, or if we should simply drop support for Condition variables.
(Fixed in Support Threads.Condition variables in Select. #3) There is another problem that I noticed, which is that the current implementation of @select leads to concurrency violations for multithreaded Thread.Conditions, because the wait(::Thread.Condition) occurs on a different task than the user's original lock(::Thread.Condition), so the unlock fails. It's the same as this MWE:
julia> c = Threads.Condition();
julia>lock(c)
julia> Threads.@spawnwait(c)
Task (failed) @0x000000011f3bad10
unlock from wrong thread
error(::String) at ./error.jl:33unlockall(::ReentrantLock) at ./lock.jl:121wait(::Base.GenericCondition{ReentrantLock}) at ./condition.jl:105
(::var"##17#18")() at ./threadingconstructs.jl:113
For the second issue above (wait occurs on a different Task), maybe there is some way to implement a custom wait() function that unlocks the parent thread? This needs to be investigated.
The text was updated successfully, but these errors were encountered:
There was a discussion starting here: julep: a @select statement JuliaLang/julia#13763 (comment) that there is a race-condition for edge-triggered events in this implementation that can cause events to be dropped. We should consider whether it's possible to fix this, or if we should simply drop support for Condition variables.
(Fixed in Support Threads.Condition variables in Select. #3) There is another problem that I noticed, which is that the current implementation of
@select
leads to concurrency violations for multithreadedThread.Condition
s, because thewait(::Thread.Condition)
occurs on a different task than the user's originallock(::Thread.Condition)
, so the unlock fails. It's the same as this MWE:For the second issue above (
wait
occurs on a different Task), maybe there is some way to implement a customwait()
function that unlocks the parent thread? This needs to be investigated.The text was updated successfully, but these errors were encountered: