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

Boehm, Hans 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.

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20071212/11840c5b/attachment.html 


More information about the Concurrency-interest mailing list