From: Robert Klemme Date: 2011-01-07T17:13:06+09:00 Subject: Re: Threading in ruby On Thu, Jan 6, 2011 at 7:14 PM, Vishnu I. wrote: > Robert Klemme wrote in post #972776: >> On Thu, Jan 6, 2011 at 11:49 AM, Vishnu I. wrote: >>>> between memories (in JVM of course). >>>> >>>> Does that help? >>> >>> oops Im sorry I wasnt clear. My question was why would I need to >>> synchronize on the read of the index variable if the synchronized write >>> has created a memory barrier between the updation of the list item and >>> the index update? Thats the only piece i couldnt follow >> >> Ah, I see.  The reason is simple: if the thread reading the resource >> does not synchronize there is no memory barrier and hence no guarantee >> that it will read a current value.  The writing thread may have >> published the current state to global memory but your reading thread >> does not necessarily have imported that change. > > aha, got it. A synchronized block guarantees that stuff in one thread > that happens before the block is visible to any other thread that is > synchronized on the same mutex.  Thanks, I get it now! I don't think this is not scoped to mutexes: a memory barrier is always a global thing. If you think about it anything else would be very inefficient - the smallest unit of memory that an operating system deals with is a page. Again, this is relevant for Java. In Ruby there is no distinction between thread local and global memory - unless you are using JRuby of course. The reason for using the same mutex for the writer and the reader thread is simply that you need *one* critical section in order to ensure only one thread accesses whatever is guarded by the mutex at a time. >> If you want to read more I suggest you google for "double checked >> locking broken".  You'll find some articles which dissect this >> seemingly good idea. >> >> From your other mail: >> >>> hmm ok Im confused now. Say the main thread completes really quickly and >>> fires available.signal 10 times in 2 minutes. Meanwhile say the updater >>> has only updated twice. Wont the third update wait forever since there >>> is no one left to signal? >> >> No, because the updater won't block if it sees that there is still >> work to do (i <= index).  It will simply continue.  You can easily >> test this out by inserting a sleep in the updater. > > oh right. That was silly of me. :) Well, multithreading is a difficult topic that few people really grok. Apparently the human brain does work concurrently internally, yet it is not well suited to reason about concurrency. :-) For example, for me initially it was difficult to get the distinction right between a Thread object and the thread of execution that is represented by it. These are really two different things and the thread of execution is only temporarily associated with the object through which it can be manipulated and queried. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/