From: Nasir Khan Date: 2007-06-12T05:42:02+09:00 Subject: Re: Synchronized attr_accessor ------=_Part_120758_21948615.1181594514144 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline While the comparison is against Java synchronization, does the Mutex#synchronize has the same behavior as synchronized in Java? I see the code under 1.8 and synchronize basically does - # File lib/thread.rb, line 132 def synchronize lock begin yield ensure unlock end end The keyword "synchronized" in Java implies not just locking but perhaps mor= e importantly "synchronization" of the current thread's working memory with heap. [JLS 17.4] The argument that you gave for explicit locking before use, is perfectly valid as long as the underlying memory model of the language does that synchronization. It is not clear to me how the above code implictly does that, this brings back to my question about Ruby Language specifications. I can understand the behavior of JRuby but how would the other Ruby interpreters be implemented for such things? If one were to implement a Ruby interpreter today where should he/she start in the absence of a language spec? Take MRI as the spec? But MRI may not be addressing all the issues like the one in question here. Am I missing something? Yes, but even the volatile keyword doesn't do what you expect. Despite widespread folklore, volatile by itself is _not_ sufficient to ensure threa= d safety -- you need to use operations which include memory barriers (generally by using the provided synchronization primitives). BTW the folklore is codified as JLS v3 and is available since Java 5. (JSR 133 fixed in 2004) "A write to a volatile variable (=A78.3.1.4) *v* synchronizes-with all subsequent reads of *v* by any thread (where subsequent is defined according to the synchronization order)." also see http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile "Under the new memory model, accesses to volatile variables cannot be reordered with each other or nonvolatile variable accesses. Writing to a volatile field has the same memory effect as a monitor release, and reading from a volatile field has the same memory effect as a monitor acquire. In effect, because the new memory model places stricter constraints on reordering of volatile field accesses with other field accesses, volatile o= r not, anything that was visible to thread A when it writes to volatile field f becomes visible to thread B when it reads f." - Nasir On 6/11/07, MenTaLguY wrote: > > On Tue, 12 Jun 2007 04:23:35 +0900, "Nasir Khan" > wrote: > > - Is it true for Ruby today? > > Depends on which implementation of Ruby. For Ruby 1.8, with its green > threads, no. For XRuby, yes. For JRuby, yes. For Rubinius, no. IronRu= by, > yes. Ruby.NET, yes. YARV/1.9, no. > > > - If not then will it ever be true in future? > > It will be also be true of Rubinius once it adds support for native > threads. It will also be true of YARV/1.9 if and when the Big Scheduler > Lock is abandoned. > > > - Is there some text somewhere where Ruby memory model for interpreter > > developers? > > No. There probably ought to be. > > > - Since Ruby doesnt have a volatile keyword does it mean that all > variable > > access is essentially non-volatile? > > Yes, but even the volatile keyword doesn't do what you expect. Despite > widespread folklore, volatile by itself is _not_ sufficient to ensure thr= ead > safety -- you need to use operations which include memory barriers > (generally by using the provided synchronization primitives). > > Incidentally, the environments where double-checked locking actually work= s > are also the ones where it gives the least performance gain. > > -mental > > > ------=_Part_120758_21948615.1181594514144--