[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Newby question: Is += atomic for integers?

rj-cole

3/1/2006 10:06:00 PM

Hi,

Can the following program produce counts that are wrong?

class Test
attr_accessor :count
def initialize
@count = 0
end
end

$test = Test.new

def my_function_called_by_many_threads
...
$test.count += 1
...
end

Any why is the following a syntax error?

class Test
def +=(value)
end
end

i.e why can't I define the += operator?

regards,

Richard.
4 Answers

Eric Hodel

3/1/2006 10:11:00 PM

0

On Mar 1, 2006, at 2:08 PM, rj-cole wrote:

> Hi,
>
> Can the following program produce counts that are wrong?
>
> class Test
> attr_accessor :count
> def initialize
> @count = 0
> end
> end
>
> $test = Test.new
>
> def my_function_called_by_many_threads
> ...
> $test.count += 1
> ...
> end

Yes. += is just syntax sugar. It gets expanded:

$ parse_tree_show -f
a += 1
[[:class,
:Example,
:Object,
[:defn,
:example,
[:scope,
[:block,
[:args],
[:lasgn, :a, [:call, [:lvar, :a], :+, [:array, [:lit, 1]]]]]]]]]

> Any why is the following a syntax error?
>
> class Test
> def +=(value)
> end
> end
>
> i.e why can't I define the += operator?

+= is not an operator, it is syntax sugar.

--
Eric Hodel - drbrain@segment7.net - http://blog.se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...

minkoo.seo@gmail.com

3/2/2006 6:15:00 AM

0

rj-cole wrote:
> Can the following program produce counts that are wrong?
>
> class Test
> attr_accessor :count
> def initialize
> @count = 0
> end
> end
>
> $test = Test.new
>
> def my_function_called_by_many_threads
> ...
> $test.count += 1
> ...
> end

Yes.

There's two problem.

(1) Even though an operation seems to be atomic, say, "a+1", it might
not be atomic in the machine level. Such an example is operations on
double, and class references. In some cases, assignment of double
variable might be done two steps.

(2) Especially if $test were shared by multiple threads which runs on
SMP, though current version of ruby core does not support it - I hope
it will - , you have to use mutex(synchronize). Otherwise, different
threads may see different values because each processor uses own cache.
This rule even applies to Java, C++, etc.

Simple and best solution to these problems is to use synchronization
whenever needed.

Minkoo Seo

Robert Klemme

3/2/2006 10:39:00 AM

0

Minkoo Seo wrote:
> rj-cole wrote:
>> Can the following program produce counts that are wrong?
>>
>> class Test
>> attr_accessor :count
>> def initialize
>> @count = 0
>> end
>> end
>>
>> $test = Test.new
>>
>> def my_function_called_by_many_threads
>> ...
>> $test.count += 1
>> ...
>> end
>
> Yes.
>
> There's two problem.
>
> (1) Even though an operation seems to be atomic, say, "a+1", it might
> not be atomic in the machine level. Such an example is operations on
> double, and class references. In some cases, assignment of double
> variable might be done two steps.
>
> (2) Especially if $test were shared by multiple threads which runs on
> SMP, though current version of ruby core does not support it - I hope
> it will - , you have to use mutex(synchronize). Otherwise, different
> threads may see different values because each processor uses own
> cache. This rule even applies to Java, C++, etc.
>
> Simple and best solution to these problems is to use synchronization
> whenever needed.

I strongly support that! Always do proper synchronization even if a non
synchronized version seems to work. It's likely to break as soon as the
code runs on another platform (e.g. Java VM). These bugs are hard to find
and also there is a documentation advantage that comes with proper MT
design.

Kind regards

robert

MenTaLguY

3/2/2006 8:01:00 PM

0

Quoting Minkoo Seo <minkoo.seo@gmail.com>:

> Simple and best solution to these problems is to use
> synchronization whenever needed.

And following from that, use as little shared state as possible
between threads, so synchronization is needed as little as
possible.

The more synchronization you use, the harder it is to get right.

-mental