[concurrency-interest] How bad can volatile long++ be?

Osvaldo Pinali Doederlein osvaldo at visionnaire.com.br
Tue Dec 11 06:28:49 EST 2007


David Holmes escreveu:
> David Gallardo writes:
>   
>> ++ is not atomic; while it may effectively be so on a single processor
>> machine, this is not the case on multiprocessor machines.
>>     
>
> It isn't the case on single processor machines either. ++ is
> read-modify-write sequence and a thread can be preempted at any point in the
> sequence.
>
> ++ is just syntatic short-hand. Write it out in full and you'd never expect
> it to be atomic.
>
>   
Perhaps the problem is that on CISC platforms like the over-popular x86, 
this /can/ be compiled down to a single instruction that does the fetch, 
increment and store on a memory address operand. People get used to 
this, they often read assembly output from compilers and see a single 
pretty, atomic instruction like INC DWORD PTR  [EBX], and expect this to 
be the rule - "it's atomic in practice". The problems is, it's not a 
portable assumption. And even in the platforms that allow this code 
generation, I'd expect the best optimizers to often /not/ do it, for 
example because they see that a new read is unnecessary on a previously 
used field, or the write can be delayed (e.g. if the increments are 
inside a loop this would provide a huge boost). I wonder, though, if any 
optimizers that could do that avoid it - giving more priority to perform 
an atomic increment - just to compensate for buggy application code?...

A+
Osvaldo
> Cheers,
> David Holmes
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>   


-- 
-----------------------------------------------------------------------
Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20071211/7255e237/attachment.html 


More information about the Concurrency-interest mailing list