[concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android
zhong.j.yu at gmail.com
Tue Apr 30 11:29:42 EDT 2013
Is it feasible for threads to observe some MESI-like protocol, so that
non-shared variables can be identified and optimized. The memory model can
claim that all variables are volatile without exception, but execution can
treat most variables as non-volatile.
On Tue, Apr 30, 2013 at 7:57 AM, Martin Thompson <mjpt777 at gmail.com> wrote:
> 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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest