Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConditionVariable#wait causes thread to wait forever in 9.2.8.0 #5863

Closed
asppsa opened this issue Sep 9, 2019 · 4 comments
Closed

ConditionVariable#wait causes thread to wait forever in 9.2.8.0 #5863

asppsa opened this issue Sep 9, 2019 · 4 comments

Comments

@asppsa
Copy link
Contributor

@asppsa asppsa commented Sep 9, 2019

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/Linux
  • This issue appears to affect only 9.2.8.0. From my testing, the issue is not present in 9.2.7.0, or in 9.1.x.
  • It does not involve any gems - just core libraries.

Expected 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.

asppsa added a commit to asppsa/jruby that referenced this issue Sep 10, 2019
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.
asppsa added a commit to asppsa/jruby that referenced this issue Sep 10, 2019
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.
@kares kares added this to the JRuby 9.2.9.0 milestone Sep 10, 2019
@headius
Copy link
Member

@headius headius commented Sep 11, 2019

Thank you for filing this one! This definitely should be fixed for 9.2.9.

@headius
Copy link
Member

@headius headius commented Oct 16, 2019

Likely the same general issue as #5875.

@headius
Copy link
Member

@headius headius commented Oct 23, 2019

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.

headius added a commit to headius/jruby that referenced this issue Oct 24, 2019
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.
@headius
Copy link
Member

@headius headius commented Oct 24, 2019

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.

@headius headius closed this in f6a9b46 Oct 26, 2019
asppsa added a commit to asppsa/jruby that referenced this issue Oct 26, 2019
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.
matthewd added a commit to gel-rb/gel that referenced this issue Mar 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants