Forum: Ruby concurrency question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Trish Ball (Guest)
on 2006-05-04 00:00
(Received via mailing list)
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
Eric H. (Guest)
on 2006-05-04 00:13
(Received via mailing list)
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. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Robert K. (Guest)
on 2006-05-04 16:37
(Received via mailing list)
2006/5/3, Eric H. <removed_email_address@domain.invalid>:
> > @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
James G. (Guest)
on 2006-05-04 17:42
(Received via mailing list)
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
Mauricio F. (Guest)
on 2006-05-04 21:36
(Received via mailing list)
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? ;-)
Eric H. (Guest)
on 2006-05-04 21:58
(Received via mailing list)
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. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
James G. (Guest)
on 2006-05-04 23:56
(Received via mailing list)
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
This topic is locked and can not be replied to.