ConditionVariable#wait causes thread to wait forever in 9.2.8.0 #5863
Comments
This tests (J)Ruby's ability to safely switch back and forth between two threads that both have locks on a single mutex, as identified in jruby#5863.
This tests (J)Ruby's ability to safely switch back and forth between two threads that both have locks on a single mutex, as identified in jruby#5863.
|
Thank you for filing this one! This definitely should be fixed for 9.2.9. |
|
Likely the same general issue as #5875. |
This does not appear to be the case. That issue is caused by us giving up on the lock immediately upon interrupt and raising an error. The correct behavior is up for debate, but probably should be checking for thread events (raise, kill) and if none exist try to acquire the lock again. |
Previous logic used the same semaphore to sleep as any other sleep which interfered with code that expected the Mutex to be the lock used. The new logic uses the Mutex's JDK Lock, via a Condition, to do the sleeping. Because it is not possible for us to change the artificial thread status we maintain to "sleep" after the lock is released, this modified logic also introduces a new thread state that indicates that the native JDK thread state should be used. This gets closer to avoiding the racing status. It does not appear to eliminate the race altogether. Fixes jruby#5863.
|
I've pushed a fix for this that actually uses the Mutex's JDK Lock to do the sleeping, via a JDK Condition. Your script runs properly now! I'm still debating the complexity of the patch, since it required us to start using the native JDK thread state rather than our tightly-controlled synthetic state. This may be fine for general use cases, but there's a few tests that have become unreliable as a result. Anyway, you can check out #5942 for the current iteration of the fix. |
This tests (J)Ruby's ability to safely switch back and forth between two threads that both have locks on a single mutex, as identified in jruby#5863.
Environment
jruby 9.2.8.0 (2.5.3) 2019-08-12 a1ac7ff OpenJDK 64-Bit Server VM 25.222-b05 on 1.8.0_222-b05 +jit [linux-x86_64]Linux managua 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 2019 x86_64 GNU/LinuxExpected Behaviour
Running this file should result in "ping" and "pong" being printed repeatedly to the screen. This works on MRI and on older versions of JRuby.
Actual Behaviour
"ping" and "pong" are printed some number of times (it varies), and then output stops. Output from Ctrl+\ indicates that both the main thread and Thread-1 are in a waiting state.
Additional info
This issue has been filed on advice from @headius, after a conversation on IRC. He has suggested that bea9ad4 is the source of the issue.
The text was updated successfully, but these errors were encountered: