From: "headius (Charles Nutter)" <headius@...>
Date: 2012-11-26T03:26:28+09:00
Subject: [ruby-core:50085] [ruby-trunk - Feature #7429] Provide options for core collections to customize behavior


Issue #7429 has been updated by headius (Charles Nutter).


trans (Thomas Sawyer) wrote:
> I wonder if concurrency behavior can be designed as a mixin. As long as the underlying class conforms to its interface then "ParallelWhatever" becomes possible. ParallelHash would then not be needed as a built-in class b/c it would be simple to define.
> 
>   class MyParallelHash < Hash
>     include Concurrency
>   end

Actually, JRuby already provides this as JRuby::Synchronized:

class MyParallelHash < Hash
  include JRuby::Synchronized
end

It's rather hacky though for a few reasons:

* In JRuby, the JRuby::Synchronized module inserts itself into the method lookup process, returning all methods wrapped with synchronization against the target object.
* The synchronization is very coarse-grained and much slower than other implementations of a concurrent data structure that would use fewer (or no) locks.
* It is not common to have the inclusion of a module change the nature of every method in the host class.

It would be better if we had some fast, always-concurrent data structures built in.
----------------------------------------
Feature #7429: Provide options for core collections to customize behavior
https://bugs.ruby-lang.org/issues/7429#change-33866

Author: headius (Charles Nutter)
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 2.0.0


Many folks know that Matz is a fan of having a few classes that handle a wide range of behavior. For this reason, I think we're unlikely to get a set of parallelism-safe collections added to Ruby. I propose an alternative that would allow parallel-executing implementations to offer concurrency-friendly versions without impact to any code.

I would like to see a way to pass in an options hash to the .new construction of at least Hash and Array. For example:

# Create a hash that is concurrenct-safe, resizes when density is > 3 keys per bucket,
# and sets initial bucket count to 60
hsh = Hash.new(concurrent: true, density: 3, size: 60)

Similar for Array:

ary = Array.new(concurrent: true, size: 100)

Options like density and size map directly to current implementation details of Hash and Array that are sometimes not accessible (you can't change the load factor for Hash, for example). Options like concurrent could be noops on MRI but would allow other implementations to provide safe versions of the collections behind the scenes.

I know it may be too late for 2.0.0, but we implementers of parallel-executing Rubies feel the pain of thread-unsafe core structures every day. I think the ability to get thread-safe collections in Ruby core would go a long way toward dispelling the myth that Ruby is bad for concurrent application programming.


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