[concurrency-interest] How bad can volatile long++ be?
hans.boehm at hp.com
Wed Dec 12 14:17:41 EST 2007
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest