[concurrency-interest] Question about re-ordering

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 17 23:17:18 EST 2012


Hi Yuval,

As David mentioned, in general compiler is free to reorder instructions
such that within same thread you cannot observe the difference (code
behaves in the same manner as if it left it alone, i.e. sequential
execution as-written); compiler would have to "prove" that it's the case,
however, in order to do that.  In your example, changing that sequence
changes sequential behavior, so it cannot do that reordering.

Vitaly

On Tue, Jan 17, 2012 at 10:42 PM, Yuval Shavit <yshavit at akiban.com> wrote:

> 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
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Vitaly
617-548-7007 (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/0632afd5/attachment-0001.html>


More information about the Concurrency-interest mailing list