[ruby-core:96101] [Ruby master Feature#16255] Make `monitor.rb` built-in

Issue #16255 has been updated by ko1 (Koichi Sasada).


I fixed `new_cond` before `mon_initialize` problem c6e3db0c66312af1e932c21006437419efa9ac75

> https://github.com/rails/rails/blob/461aae05f194f775e6367be9add4dda37746bd5c/activesupport/lib/active_support/concurrency/load_interlock_aware_monitor.rb#L7-L15

This code depends "how to implement `#synchronize`" so that I'm not sure MRI should support it for compatibility (I don't think so, if most of people doesn't use this technique).


----------------------------------------
Feature #16255: Make `monitor.rb` built-in
https://bugs.ruby-lang.org/issues/16255#change-82961

* Author: ko1 (Koichi Sasada)
* Status: Closed
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version: 
----------------------------------------
# Abstract

`monitor.rb` introduces `MonitorMixin` module and `Monitor` class.
Now, `rubygems.rb` requires `monitor.rb` so that most of Ruby applications (*1) requires `monitor.rb` 

[*1] running MRI with `--disable-gems` can eliminate `monitor.rb`, but only a few people use this option.

Also recent changes (6ec1720aa38772ba4b7515790443cb578340518b and so on) to make it atomic introduces several overhead.
Making them in C will avoid such overhead.

Naruse-san made monitor-ext gem to make it faster by making C-extension.
This proposal is to make it built-in class.

# Approach

Implement `Monitor` class as re-entrant mutex object in C and implement `MonitorMixin` with it.
Now, `Monitor` class is implemented with `MonitorMixin`, but it is easy to implement `Monitor` class directly and faster in C.

`MonitorMixin` and `MonitorMixin::ConditionalVariable` are remained in `lib/monitor.rb`, because it is easy to write :p

# Implementation

https://github.com/ruby/ruby/compare/master...ko1:thread_monitor

# Evaluation

```
require_relative 'benchmark/lib/load'
Benchmark.driver(repeat_count: 1){|x|
  x.executable name: '2.5.2', command: %w'/home/ko1/ruby/install/ruby_2_5/bin/ruby'
  x.executable name: '2.6.6', command: %w'/home/ko1/ruby/install/ruby_2_6/bin/ruby'
  x.executable name: 'trunk', command: %w'/home/ko1/ruby/install/trunk/bin/ruby'

  x.prelude %{
    mon = Monitor.new
  }

  x.report %{
    mon.synchronize{
      mon.synchronize{
      }
    }
  }
}

#=>
# trunk:   4345545.8 i/s
# 2.5.2:   1657762.1 i/s - 2.62x  slower
# 2.6.6:    499165.7 i/s - 8.71x  slower
```

# Discussion

`Queue`, `Mutex` are the alias of `Thread::Queue`, `Thread::Mutex`.

```ruby
p Queue #=> Thread::Queue
```

I defined `Thread::Monitor` and make alias by `Monitor = Thread::Monitor`. Is it okay?

I removed `mon_` prefix methods from `Monitor` class. I believe they are only for `MonitorMixin`.

... but I found two examples which call mon_ prefix methods for `Monitor` class:

```
/home/gem-codesearch/gem-codesearch/latest-gem/gel-0.3.0/lib/gel/db.rb:      @monitor.mon_owned?
/home/gem-codesearch/gem-codesearch/latest-gem/keepyourhead-0.2.2/lib/Keepyourhead/Cache.rb:            @monitor.mon_synchronize {
```

Should we obsolete them for `Monitor` class?




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

Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>