From: Eric Wong Date: 2016-02-05T21:42:34+00:00 Subject: [ruby-core:73718] Re: [CommonRuby Feature#12020] Documenting Ruby memory model email@pitr.ch wrote: > Thank you, for taking time to read it and for your input. I apologise > for delayed answer, I was rather busy lately. No worries, I've been busy, too. > I've added following paragraph to the document explaining a little bit > why volatility is preferred. > > "The volatile property has noticeable impact on performance, on the > other hand it���s often quite convenient property, since it simplifies > reasoning about the program. Therefore unless it presents a > performance issue volatility is preferred." > > It tries to be in alignment with rest of the Ruby language to be > user-friendly. Therefore the volatility behaviour is on Constants and > similar. I've also elaborate in the document in the Constants part why > is there no performance loose by making them volatile: "Ruby > implementations may take advantage of constancy of the variables to > avoid doing volatile reads on each constant variable read. MRI can > check a version number. For MRI, checking a version number still requires a memory model of that version number to be defined. I'd rather not have consitency guarantees of the version number. This goes for constants and methods at least, which are already versioned in MRI. > > Maybe volatility for require/autoload is a special case only iff a > > method/constant is missing entirely; but hitting old methods/constants > > should be allowed by the implementation. > > Volatility of require/autoload and the fact that it blocks when other > thread is loading given file/constant are very useful in parallel > environment to make sure that some feature/class is fully loaded > before using it. Both are usually used only on program paths which run > only once during loading or reloading, therefore there are not > performance critical. Agreed. So perhaps missing constant/method falls back to (volatile|synchronous|coherent) checking. However, redefined/included/extended existing constant/methods should only be eventually consistent; they may be cached locally per-thread. > > 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. > I've tried to explain little bit in the document, this should not have > any overhead. MRI with GIL does not have to ensure read-after-write > consistency, other compiling implementations are actively invalidating > the compiled code if it depends on a constant which was just redefined > (or a method). MRI has GIL today, I do not want MRI to have a GIL in the future. To give us the most freedom in the future, I prefer we have as few guarantees as practical about consistency. > I did not entirely understood why you are against volatility on > constants and methods, I tried to explain better why they are > suggested to be volatile though. Could you elaborate? See above :> Any version checks for thread-specific caches would need to define the consistency of the version number itself. Unsubscribe: