[#97678] [Ruby master Feature#16752] :private param for const_set — bughitgithub@...
Issue #16752 has been reported by bughit (bug hit).
5 messages
2020/04/02
[ruby-core:97910] [Ruby master Feature#16792] Make Mutex held per Fiber instead of per Thread
From:
samuel@...
Date:
2020-04-16 09:24:21 UTC
List:
ruby-core #97910
Issue #16792 has been updated by ioquatix (Samuel Williams). Characterising this as trivial hides the impact of this both on the scheduler design and application code which expects per-thread mutex. Once the scheduler lands into master, we will need to scope out something like `wait_mutex` and all the associated scheduling that needs to happen. Can you check the Crystal implementation? How do they implement fair scheduling? Finally, as this breaks assumptions about user code, I proposed `Mutex.new(blocking: false/true)`. I'm on the fence regarding this interface, but at least it should be clear that such a change has a track record of breaking application code. So if we decide to make the mutex per-fibre, we need to anticipate this problem, either through analysis of existing source code, issuing warnings, or something else. Ultimately, I think keeping it simple would be great. But I'm hesitant to do so since it may break existing code. @headius maybe you can comment on what user code was affected so we can see if there is some other way to mitigate it. ---------------------------------------- Feature #16792: Make Mutex held per Fiber instead of per Thread https://bugs.ruby-lang.org/issues/16792#change-85135 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- Currently, Mutex in CRuby is held per Thread. In JRuby and TruffleRuby, Mutex is held per Fiber (because it's simply easier implementation-wise). While a user could theoretically notice the difference, it seems extremely uncommon in practice (probably incorrect synchronization). The usage pattern for a Mutex is using #synchronize or lock+unlock. Such a pattern protects/surrounds a region of code using some resource, and such a region of code is always on the same Fiber since it's on a given Ruby "stack". With #16786 it becomes more relevant to have Mutex held per Fiber, otherwise Mutex#lock will hurt scalability of that proposal significantly. This means, if a Fiber does Mutex#lock and it's already held by another Fiber of the same Thread, and the Thread#scheduler is enabled, instead of just raising an error (which made sense before, because it would be a deadlock, but no longer the case with scheduler), or disabling fiber scheduling entirely until #unlock (current state in #16786, makes Mutex#lock special and hurts scalability), we would just go to the scheduler and schedule another Fiber (for instance, the one holding that Mutex, or any other ready to be run Fiber). This is not a new idea and in fact Crystal already does this with its non-blocking Fibers, which is very similar with #16786: https://github.com/crystal-lang/crystal/blob/612825a53c831ce7d17368c8211342b199ca02ff/src/mutex.cr#L72 Mutex#lock is just like other blocking operations, so let's make it so building on #16786. I believe it's the natural and intuitive thing to do for Fiber concurrency with a scheduler. Queue#pop and SizedQueue#push could be other candidates to handle in a similar way. Here is an early commit to make Mutex held per Fiber, it's quite trivial as you can see: https://github.com/ruby/ruby/compare/master...eregon:mutex-per-fiber It passes test-all and test-spec. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
