[concurrency-interest] Question about re-ordering

Yuval Shavit yshavit at akiban.com
Tue Jan 17 22:42:52 EST 2012


This isn't concurrency related, but since we're talking about reordering,
I've sometimes wondered what in the spec prevents the compiler from turning
this:

    long start = System.nanoTime();
    someMethod();
    long end = System.nanoTime();
    long time = end - start;

into the much less useful:

    long start = System.nanoTime();
    long end = System.nanoTime();
    someMethod();
    long time = end - start;

or even:

    long end = System.nanoTime();
    long start = System.nanoTime();
    someMethod();
    long time = end - start;

Obviously it's important that the actions not be reordered, but what
prevents it? More generally, is there any definition in the JLS of what
sorts of actions can and can't be reordered within a thread? I've looked a
few times and have never found anything. Is there some sort of reordering
fence at IO?

On Tue, Jan 17, 2012 at 6:26 PM, David Holmes <davidcholmes at aapt.net.au>wrote:

> From a theoretical perspective actions within a thread must appear to occur
> in program order, but any reordering is allowed that would not be visible
> by
> the thread. In practice without some aggressive inlining, and only if
> intervening functions are trivially small, it is not likely that any
> instructions from clear() would be reordered with any from put(). A
> compiler
> is not going to reorder two method calls unless it can ascertain it is
> correct to do so - which in general it can not do.
>
> David Holmes
>
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Nader
> > Aeinehchi
> > Sent: Wednesday, 18 January 2012 9:12 AM
> > To: concurrency-interest at cs.oswego.edu
> > Subject: [concurrency-interest] Question about re-ordering
> >
> >
> > Hi
> >
> > In the following, a listener is notified by some configurator.  Question
> > is whether a re-ordering may be enforced by compiler on the operations
> > on "stateMap"?  Is it safe to assume that stateMap.clear() is always run
> > before stateMap.put within the same thread?
> >
> >      public void notify(ConfigurationEvent event) {
> >          if (event.getType() == AbstractFileConfiguration.EVENT_RELOAD) {
> >              logger.warn("log something");
> >
> >              stateMap.clear();
> >
> >              List<SubnodeConfiguration> configurations =
> > xmlConfiguration.configurationsAt("*");
> >              for (SubnodeConfiguration subnodeConfiguration :
> > configurations) {
> >
> > stateMap.put(subnodeConfiguration.getString("@configurationId"), new
> > State(subnodeConfiguration));
> >              }
> >          }
> >      }
> >
> > Thanks
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
> _______________________________________________
> 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/20120117/2790bec3/attachment.html>


More information about the Concurrency-interest mailing list