From: "Vishnu I." Date: 2011-01-07T03:14:02+09:00 Subject: Re: Threading in ruby 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! > > 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. :) -- Posted via http://www.ruby-forum.com/.