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.
De8c393deb01f7157eb4ce896a2cd4a6?d=identicon&s=25 Trish Ball (Guest)
on 2006-05-03 22: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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-03 22: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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-04 14:37
(Received via mailing list)
2006/5/3, Eric Hodel <drbrain@segment7.net>:
> > @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
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-04 15:42
(Received via mailing list)
On May 4, 2006, at 7:34 AM, Robert Klemme 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 Gray II
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2006-05-04 19:36
(Received via mailing list)
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).

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? ;-)
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-04 19:58
(Received via mailing list)
On May 4, 2006, at 6:40 AM, James Edward Gray 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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-04 21:56
(Received via mailing list)
On May 4, 2006, at 12:55 PM, Eric Hodel 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 Gray II
This topic is locked and can not be replied to.