Feature #21788: Promote Thread::Monitor to a core class

• Status: Open
• Assignee: -
• Target version: 4.1

[byroot (Jean Boussier)]

Monitor is about as useful as Mutex and yet one is a core class and the other is a "stdlib" extension.

I propose to promote Thread::Monitor as a core class convenience.

The rest of monitor.rb

The monitor stdlib also contains MonitorMixin, but I think this part can remain in lib/monitor.rb (or even be moved to lib/monitor_mixin.rb.

One more questionable part is Monitor#new_cond, as it returns a ::MonitorMixin::ConditionVariable so it would also need to remain in the stdlib.

Performance benefit

By being a core class, Monitor can also be implemented more efficiently, as it is no longer constrained to the public C API.
On my branch, monitor is approximately 15% faster (but there might be some more optimizations to be found).

master:

ruby 4.0.0dev (2025-12-17T07:16:32Z master 54d3945ee5) +YJIT +PRISM [arm64-darwin25]
Warming up --------------------------------------
               Mutex     1.952M i/100ms
             Monitor     1.775M i/100ms
Calculating -------------------------------------
               Mutex     25.102M (± 0.4%) i/s   (39.84 ns/i) -    126.884M in   5.054731s
             Monitor     21.189M (± 0.1%) i/s   (47.19 ns/i) -    106.485M in   5.025493s

core monitor:

ruby 4.0.0dev (2025-12-17T07:21:34Z core-monitor 32815a1bc4) +YJIT +PRISM [arm64-darwin25]
Warming up --------------------------------------
               Mutex     1.975M i/100ms
             Monitor     1.936M i/100ms
Calculating -------------------------------------
               Mutex     25.213M (± 0.4%) i/s   (39.66 ns/i) -    126.407M in   5.013728s
             Monitor     24.099M (± 0.1%) i/s   (41.50 ns/i) -    121.992M in   5.062092s

Proposed implementation: https://github.com/ruby/ruby/pull/15538

[Eregon (Benoit Daloze)]

+1

I think MonitorMixin and MonitorMixin::ConditionVariable are small enough that it would be good to have them in core too.
BTW wait_while/wait_until are good patterns and maybe something Thread::ConditionVariable should have too, out-of-topic I know but the point is MonitorMixin seems well done and core-worthy.
mon_initialize could also be made safer potentially if it's made core, e.g. to use an internal lock on the object (or the GVL) or so.

[byroot (Jean Boussier)]

• Description updated (diff)

[byroot (Jean Boussier)]

the point is MonitorMixin seems well done and core-worthy.

Yeah, I don't think I agree with this. I never use it because including it expose a bunch of mon_* public methods that nobody ever use.
At the end of the day 99% of Monitor usage is just:

class MyClass
  def initialize
    @monitor = Monitor.new
  end

  def some_method
    @monitor.synchronize do
      # do thing
    end
  end
end

I really see no value in the mixin.