Use Mutex#owned? to correctly check if the Mutex is owned by the current Thread or Fiber

[eregon]

• In Ruby >= 3, Mutex are held per Fiber, not per Thread.
• Fixes ThreadError: Attempt to unlock a mutex which is locked by another thread/fiber #501

Based on #502 (comment)
Seems a better alternative to #502.

[ioquatix]

Great insight and improved implementation. Well done.

[pirj]

It's strange, on 3.0.0 it fails locally for me (macOS 10.14.6):

Failures:

  1) RSpec::Support::ReentrantMutex waits when trying to lock from another Fiber
     Failure/Error:
       expect {
         mutex.send(:enter)
         raise 'should reach here: mutex is already locked on different Fiber'
       }.to raise_error(Exception, 'waited correctly')

     Exception:
       waited correctly
     # /Users/pirj/source/rspec-dev/repos/rspec-expectations/lib/rspec/matchers.rb:771:in `require'
     # /Users/pirj/source/rspec-dev/repos/rspec-expectations/lib/rspec/matchers.rb:771:in `raise_error'
     # ./spec/rspec/support/reentrant_mutex_spec.rb:38:in `block (4 levels) in <top (required)>'

Finished in 0.02348 seconds (files took 0.39513 seconds to load)
4 examples, 1 failure

Wondering if Thread.pass's behavior is platform-specific ("A running thread may or may not switch"):

 pass → nil click to toggle source

Give the thread scheduler a hint to pass execution to another thread. A running thread may or may not switch, it depends on OS and processor.

Installing 3.0.1 and reinstalling 3.0.0 to understand if there is a difference, as CI seems to be using 3.0.1:

Installing Bundler
  /opt/hostedtoolcache/Ruby/3.0.1/x64/bin/gem install bundler -v ~> 2 --no-document

[pirj]

No worries on 1.8 and 1.9 failures, we can conditionally define different method implementations for ReentrantMutex, we even already do this in if defined? ::Mutex.

[pirj]

Same failure for me on 3.0.1. @eregon do you think it is possible to change the test not to rely on platform-specific behaviour?

[eregon]

The message above looks a bit like a bug of the raise_error matcher.
What I guess it is that the Thread uses a sleep status before mutex.send(:enter), I'll add a check to make sure that's not the case.
Thread.pass is fine, it's not platform-specific to wait for another thread with it.

[eregon]

The test should work reliably now.

[eregon]

@pirj Could you make this PR work for 1.8?
I'm not willing to spend time on fixing such ancient Rubies (not even supported anymore by anyone).

Alternatively, we could target this PR at RSpec 4 I guess, WDYT @ioquatix?

[eregon]

Unfortunately I can't even see the CI running due that change done by GitHub :/ (https://twitter.com/eregontp/status/1387472155567394820)

[eregon]

Retargeted to 4-0-dev and then it can be backported if wanted.

[pirj]

The test should work reliably now.

Works seamlessly.

can't even see the CI running due that change done by GitHub

An inconvenience at least.

Could you make this PR work for 1.8?
I'm not willing to spend time on fixing such ancient Rubies

I understand. No problem, I'll take care of backporting.

Thanks a lot for putting your time in this, @eregon !

[pirj]

@JonRowe @benoittgt I intend to merge on green, since it's for RSpec 4.0, and will send a backport PR for RSpec 3.

[ioquatix]

Amazing work everyone!