[concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android
hans.boehm at hp.com
Tue Apr 30 20:48:01 EDT 2013
A nice simple example to consider here is a user application that declares an array, and calls a library to sort it. The sort library uses a parallel sort that relies on a sequential sort to sort small sections of the array. In a sequential-by-default world, how would you declare the parallel sections? Would it be any different than what we do now? The user application that declares the array may never know that there is any parallel code involved. Nor should it.
Applications such as this are naturally data-race-free, thus there is no issue with the compiler "breaking" code. And the compiler can apply nearly all sequentially valid transformations on synchronization-free code, such as the sequential sort operations. If you accidentally introduce a data race bug, it's unlikely your code would run correctly even if the compiler guaranteed sequential consistency. Your code may be a bit easier to debug with a hypothetical compiler that ensures sequential consistency. But so long as you avoided intentional (unannotated) data races, I think a data race detector would also make this fairly easy.
From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Martin Thompson
Sent: Tuesday, April 30, 2013 5:57 AM
To: Kirk Pepperdine
Cc: Gregg Wonderly; concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android
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 regions.
Date: Tue, 30 Apr 2013 07:38:01 +0200
From: Kirk Pepperdine <kirk at kodewerk.com<mailto:kirk at kodewerk.com>>
To: Gregg Wonderly <gergg at cox.net<mailto:gergg at cox.net>>
Cc: concurrency-interest at cs.oswego.edu
<mailto: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<mailto: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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest