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

Osvaldo Pinali Doederlein osvaldo at visionnaire.com.br
Wed Dec 12 16:51:15 EST 2007


Hi,
>
>     ------------------------------------------------------------------------
>     *From:* Osvaldo Pinali Doederlein
>
>     I am aware of the produced bytecode and other issues you mention.
>     So I think I was not very clear in my comment, so trying again:
>     1) Code like the inc() below can be compiled down to a single
>     instruction, which (at least on singleprocessors as several people
>     pointed) is an atomic instruction. (*) Even on
>     multicore/multiprocessors, I think the instruction will be atomic,
>     provided that the long value is aligned to 8 bytes, which
>     typically (always?) has the nice side effect of making sure the
>     value doesn't straddle cache-line boundaries, so, no atomicity
>     problems with the propagation of writes through the memory
>     hierararchy. 
>      
>
> On X86, an increment instruction is not atomic on a multiprocessor (or 
> presumably with "hyperthreading") unless it has a "lock" prefix.   The 
> lock prefix normally adds SUBSTANTIAL (order of a dozen to hundreds of 
> cycles) overhead, and is unlikely to be generated without good reason.
>  
> Hans
Sorry, when I wrote that comment I was thinking too hard about 
Consistency, not Atomicity. I meant that the alignment should prevent, 
for example, that thread 1 writes 0x0000000000000000 and thread 2 
concurrently writes 0xFFFFFFFFFFFFFFFF, and the result in memory is 
something like 0x00000000FFFFFFFF due to bad luck in cache-RAM sync'ing; 
but that's all (but correct me again if I am wrong even in this assumption).

A+
Osvaldo

-- 
-----------------------------------------------------------------------
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/20071212/d47b697d/attachment.html 


More information about the Concurrency-interest mailing list