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
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.
On May 3, 2006, at 12:58 PM, Trish Ball wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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
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.
--
Have a look: http://www.flickr.com/photos/fussel-foto/
> 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).
James Edward Gray II
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:
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? 
On Thu, May 04, 2006 at 10:40:19PM +0900, James Edward Gray 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).
--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
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.
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).
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
You're right of course. My bad.
James Edward Gray II
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.