[concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android

Martin Thompson mjpt777 at gmail.com
Tue Apr 30 08:57:04 EDT 2013

I agree with Kirk here and would take it further.  By default the vast
majority of code should be single threaded and concurrent programming is
only utilized in regions of data exchange.

If all code was sequentially consistent then most hardware and compiler
optimizations would be defeated.  A default position that all code is
concurrent is sending the industry the wrong way in my view.  It makes a
more sense to explicitly define the regions of data exchange in our
programs and therefore what ordering semantics are required in those


Message: 3
Date: Tue, 30 Apr 2013 07:38:01 +0200
From: Kirk Pepperdine <kirk at kodewerk.com>
To: Gregg Wonderly <gergg at cox.net>
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] JLS 17.7 Non-atomic treatment of
        double  and long : Android
Message-ID: <5D85887E-8BFE-4F09-AFA8-53FE1DFD52D3 at kodewerk.com>
Content-Type: text/plain; charset="windows-1252"
Sorry but making thing volatile by default would be a horrible thing to do.
Code wouldn't be a bit slower, it would be a lot slower and then you'd end
up with the same problem in reverse!
On 2013-04-30, at 12:10 AM, Gregg Wonderly <gergg at cox.net> wrote:
> This code exists everywhere on the Java JVM now, because no one expects
the loop hoist?   People are living with it, or eventually declaring the
loop variable volatile after finding these discussions.
> Java, by default, should of used nothing but volatile variables, and
developers should of needed to add non-volatile declarations via
annotations, without the 'volatile' keyword being used, at all.
> That would of made it hard to "break" code without actually looking up
what you were doing, because the added verbosity would only be tolerated
when it actually accomplished a performance improvement.  Today, code is
"Faster" without "volatile".   If everything was "volatile" by default,
then code would be slower to start with, and proper "concurrency
programming" would then make your code faster, as concurrency should.
> Gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130430/24fb6bd7/attachment.html>

More information about the Concurrency-interest mailing list