Issue #12020 has been updated by Benoit Daloze.


Eric Wong wrote:
>  I'm not sure if shared memory is even a good model for Ruby (and not my
>  decision).  Anyways, my comments below if matz/ko1 decide to go down
>  this route.

Shared memory at the user level is only one possibility indeed.
But it is one the current model supports, even if MRI prevents actual parallelism.
Also, for a memory model we must take the bottom layer, which seems shared memory here.

>  Anyways, I am not convinced (volatile|synchronous|coherent) access
>  should happen anywhere by default for anything because of costs.

>  I strongly disagree with volatility in method and constant tables. Any
>  programs defining methods/constants in parallel threads and expecting
>  them to be up-to-date deserve all the problems they get.

The idea is it's only volatile/coherent for storages which are naturally "global"
*and* where the performance overhead is very limited.

As Petr said, the impact on constants is only for the uncached case,
which is already much slower than a cached constant lookup.

For methods it is very similar as Ruby implementations invalidate
the method caches when the method table is changed, which mean
there is only a minor overhead on method lookup for populating the cache.

On MRI, there is of course no overhead since the GIL guarantees these properties and much more.

>  The inline, global (, and perhaps in the future: thread-specific)
>  caches will all become expensive if we need to ensure read-after-write
>  consistency by checking for changes on methods and constants made
>  by other threads.

You are right, inline caches would have overhead on some platforms,
unless some form of safepoints/yieldpoints are available to the VM to clear the caches or ensure visibility
(with a serial number check, it could just ensure visibility of the new serial to every thread).
If the VM actually runs Ruby code in parallel, then it also most likely uses safepoints
for the GC so I would guess Ruby VMs either have them or do not run Ruby code in parallel.

The global cache could use a similar approach to avoid overhead.

With this, the overhead would be limited to the slow path method/constant lookup and the additional cost to invalidate.

----------------------------------------
Feature #12020: Documenting Ruby memory model
https://bugs.ruby-lang.org/issues/12020#change-56889

* Author: Petr Chalupa
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Defining a memory model for a language is necessary to be able to reason about a program behavior in a concurrent or parallel environment. 

There was a document created describing a Ruby memory model for concurrent-ruby gem, which fits several Ruby language implementations. It was necessary to be able to build lower-level unifying layer that enables creation of concurrency abstractions. They can be implemented only once against the layer, which ensures that it runs on all Ruby implementations.

The Ruby MRI implementation has stronger undocumented guaranties because of GIL semantics than the memory model, but the few relaxations from MRIs behavior allow other implementations to fit the model as well and to improve performance.

This issue proposes to document the Ruby memory model. The above mentioned memory model document which was created for concurrent-ruby can be used as a starting point: https://docs.google.com/document/d/1pVzU8w_QF44YzUCCab990Q_WZOdhpKolCIHaiXG-sPw/edit#. Please comment in the document or here.

The aggregating issue of this effort can be found [here](https://bugs.ruby-lang.org/issues/12019).



-- 
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>