Re: Threading in ruby

On Tue, Jan 4, 2011 at 10:53 AM, Vishnu I. <[e-mail]> wrote:
> Robert Klemme wrote in post #972187:
>> On Tue, Jan 4, 2011 at 8:41 AM, Vishnu I. <[e-mail]> wrote:

>>> but is it safe to move the list updation
>>> outside? (I assume no since regular statements and sych blocks can get
>>> reordered).
>>
>> There is no list update. =A0You only update Hash instances contained in
>> the Array. =A0With your logic it should be safe to only synchronize on
>> the index access because you modify only those entries in the Array
>> with index > current index.
>
> This is the part that I'm not sure about. If I synchronize only on
> updation of the index, there's nothing preventing the runtime from first
> updating the index and THEN updating the hash in the array. unless
> sychronizing guarantees that all statements prior to the synchronized
> block are executed.

In Java - which has far more sophisticated threading and memory model
than MRI - it would also be sufficient to only synchronize the index
modification.  The reason is that in Java each synchronized block has
two memory barriers - one on entry and one on exit.  The JVM is only
allowed to reorder execution between two memory barriers but it is
never allowed that reordering of statements moves execution of a
statement across a memory barrier.

>>> Also I have sychronized in the updater thread because I dont
>>> know if statements inside sychronized blocks can be re-ordered. Is that
>>> right?
>>
>> Not sure what you mean here. =A0You properly synchronize access to index
>> which is exactly what you need to do to make the code safe.
>
> sorry, what I meant was inside the top synchronized block I update the
> hash and the index. But again there are no guarantees about the order in
> which these actions happen. So I have to synchronize on the mutex while
> retrieving index too.

Yes, of course.  If you want to make access to a resource thread safe
you must synchronize *all* accesses.  That's the simple rule to make
code thread safe.  Only the change of the Hash in the Array does not
need to be synchronized.  In fact, you should strive to make
synchronized sections as short as possible to avoid unnecessary
contention.

>>> p.s. After I considered this solution, I came to know about the Queue
>>> classin thread, so I know that that is a more elegant solution. But I
>>> would still like to know the solution.
>>
>> https://gist.github.com/764540
>
> oops I wasnt clear at all here I see :o. I meant I understood and got
> the solution working with queues. I was wondering how to solve this
> problem with locks :)

Well, I chose to ignore what you wanted and instead present what I
would consider a better solution. :-)

The solution without queue would involve a ConditionVariable.  This is
more appropriate than using sleep:

https://gist.github.com/764540#file_sc2.rb

Kind regards

robert


--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/