On May 4, 2006, at 12:55 PM, Eric Hodel wrote:

> On May 4, 2006, at 6:40 AM, James Edward Gray II wrote:
>
>> On May 4, 2006, at 7:34 AM, Robert Klemme wrote:
>>
>>> 2006/5/3, Eric Hodel <drbrain / segment7.net>:
>>>> On May 3, 2006, at 12:58 PM, Trish Ball wrote:
>>>>
>>>> > I am new to concurrency issues, and am working with DRb (also  
>>>> new to
>>>> > this).  My DRb class assigns a value to an instance variable  
>>>> that will
>>>> > be accessed by my client.  Is there a possibility with a  
>>>> concurrency
>>>> > issue if the client tries the access that variable when it is  
>>>> being
>>>> > assigned.
>>>>
>>>> No.
>>>>
>>>> > @list = LabelList.new(@label_list)
>>>> >
>>>> > Will I need a mutex around this?
>>>>
>>>> It will see either the old value or the new value.  Nothing will
>>>> break otherwise.
>>>
>>> IMHO this cannot be answered correctly with the information we  
>>> have so
>>> far.
>>
>> The example had one client reading the value and one server  
>> setting it.  Under those circumstances, I think Eric's answer is  
>> right on.
>>
>>> You are right with regard to assignment semantics (i.e.
>>> assignment is atomic in current Ruby runtime)
>>
>> I'm fairly certain assignment is not an atomic action in Ruby.   
>> There's a pretty good example of this on page 142 of the PickAxe  
>> (2nd Edition).
>
> Assignment is atomic.  The example in the pickaxe shows that += is  
> not atomic because it is two operations, not one.  When performing  
> similar operations the code will need to be wrapped in a Mutex.

You're right of course.  My bad.

James Edward Gray II