Issue #12020 has been updated by Koichi Sasada.


Sorry for late to comment on this topic.
(and sorry i don't read all of comments on this topic)

At first, I need to appreciate you for such a great document.

However, my opinion is negative.
Basically, (at least on MRI) *I* against this proposal because it is too difficult to understand and to implement.
I believe we should introduce memory consistency model on more higher-level abstraction, like Go language does.

### Difficulty of understanding

For example, JSR-133 is well documented by great people.
But I'm not sure how many people understand it correctly very details (and evils are in details).

To make it easy, we need to introduce more clear, more little rules with higher level abstraction.

### Difficulty of implementation

As you know, there are various computer architectures enabling shared memory parallel computing with different memory consistency model.
I'm not sure we can enable to implement on all of them.

For example (trivial example), your all "atomicity" fields are true,
but I'm not sure how to implement them correctly on Float value (as you write in the middle of this document) on any computer architecture.

As you know, some computers reorder memory access.
To serialize them, we need to issue extra instructions.
Maybe we need to issue them many times if we need to satisfies all of them.

Also strict rules will become hurdles for future optimizations.

On MRI, we don't need to care with such memory access reordering
because MRI uses pthread_mutex (or similar API) on switching.

### Note

This is my opinion, and also Matz had agreed with this opinion.

However, it is only personal opinion.
We need to discuss about it.
So that your contribution is great.


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

* Author: Petr Chalupa
* Status: Assigned
* Priority: Normal
* Assignee: Koichi Sasada
----------------------------------------
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>