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

Zhong Yu 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.

Zhong Yu



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
> regions.
>
> Martin...
>
> ------------------------------
> 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!
> Regards,
> Kirk
> 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130430/bc3d617e/attachment.html>


More information about the Concurrency-interest mailing list