Concurrency question

Ruby
1

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.

i.e…

@list = LabelList.new(@label_list)

Will I need a mutex around this?

Thanks,
Trish

2

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.

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

3

2006/5/3, Eric H. [email protected]:

@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. You are right with regard to assignment semantics (i.e.
assignment is atomic in current Ruby runtime) but inconsistencies
might still occur if the object is to be changed or if there are other
instance variables that have to be changed consistently. It really
depends on the application context.

Kind regards

robert

4

On May 4, 2006, at 7:34 AM, Robert K. wrote:

assigned.
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).

James Edward G. II

5

On Thu, May 04, 2006 at 10:40:19PM +0900, James Edward G. II wrote:

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).

Could you show that example?
If it’s a variant of

count = 0
(1…100).map do
Thread.new { 10000.times { count += 1 } }
end.each{|x| x.join}
count # => 590000

it’s not saying quite the same thing (>no atomic sugar heh).

Besides, how would a regular assignment (foo = 1) be non-atomic?..
getting
half a VALUE written, with the subsequent crash? :wink:

6

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

that will

Will I need a mutex around this?
right on.
similar operations the code will need to be wrapped in a Mutex.
You’re right of course. My bad.

James Edward G. II

7

On May 4, 2006, at 6:40 AM, James Edward G. II wrote:

concurrency
It will see either the old value or the new value. Nothing will
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.

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com