From: "byroot (Jean Boussier)" <noreply@...>
Date: 2022-11-05T17:19:01+00:00
Subject: [ruby-core:110624] [Ruby master Bug#17827] Monitor is not fiber safe

Issue #17827 has been updated by byroot (Jean Boussier).


Yeah of course.

I'm trying to look at it, but not 100% sure what the condition should be.

Something like:

```ruby
monitor.owner.thread == current_fiber.thread && !fiber_scheduler
```

In other word, if we're trying to enter a monitor currently owned by another fiber belonging to the same thread than us, and there is no fiber scheduler registered.

If so the issue will be to get the thread_id or ptr of a fiber, because `monitor` is an extension and I don't see anything in the public API that allows to tell that.

One way I guess is I can store `rb_thread_current()` in the monitor struct, it's a bit redundant but would work I think.

----------------------------------------
Bug #17827: Monitor is not fiber safe
https://bugs.ruby-lang.org/issues/17827#change-99956

* Author: ioquatix (Samuel Williams)
* Status: Closed
* Priority: Normal
* Assignee: Eregon (Benoit Daloze)
* Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: DONE
----------------------------------------
According to our discussion here https://github.com/rspec/rspec-support/issues/501 it seems like typical implementation of per-thread reentrant mutex is no longer valid and can lead to some deadlock situation.

```
#!/usr/bin/env ruby

require 'monitor'

def monitor_failure
	m = Monitor.new
	
	f1 = Fiber.new do
		m.synchronize do
			puts "f1 A"
			Fiber.yield
			puts "f1 B"
		end
	end
	
	f2 = Fiber.new do
		m.synchronize do
			puts "f2 A"
			# Fiber.yield
			f1.resume
			puts "f2 B"
		end
	end
	
	f1.resume
	f2.resume
end

monitor_failure
```



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>