From: Sean O'Halpin <sean.ohalpin@...>
Date: 2013-02-25T05:08:30+09:00
Subject: Re: Ruby Multithreaded producer-consumer problem

On Sun, Feb 24, 2013 at 4:23 PM, Robert Klemme
<shortcutter@googlemail.com> wrote:
> On Sun, Feb 24, 2013 at 4:51 PM, Abhijit Sarkar <lists@ruby-forum.com> wrote:
>
>> Sean O'halpin wrote in post #1098770:
>
>>> - the only shared state you need to protect access to is the
>>> @orange_count variable - it's unnecessary to use synchronize around
>>> the whole loop.
>> True. I thought then that @age also needs protection but on closer
>> review now, it doesn't.
>
> Access to at least these variables needs proper synchronization:
> Worker@next_run
> OrangeTree@age
> OrangeTree@orange_count
>

Hi,

I think we must have been looking at different versions of the code -
there's no @next_run in the version I responded to
(http://www.ruby-forum.com/attachment/8128/orange_tree.rb). I guess I
should have made it clear which version I was trying to fix (there
appear to be quite a few). Note, I did mistakenly point to the OP's
first version in the description of the gist I wrote but that does not
use @next_run either. I take it you didn't look at
https://gist.github.com/seanohalpin/5023887.

Also, why would @age need synchronization?

>>> - you don't check whether the exit condition for the orange_picker
>>> thread is true before waiting on the CV. This will halt your thread
>>> indefinitely when the age_increaser thread exits before the
>>> orange_picker thread starts the wait.
>
> No.  If the age_increaser exits before the orange_picker starts to
> wait it means that it will have set @next_run to :orange.
> orange_picker won't block then.
>
>> THIS was causing the deadlock.

Like I said, there's no @next_run in the version I responded to.
You're right for the version of the code you're referring to. Putting
the check on age in worked for the version I was looking at.

Regards,
Sean