[concurrency-interest] Question about re-ordering

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


Also, forgot to mention -- an optimizing compiler is an implementation
detail.  You can have a JVM that does no optimizations -- code executes as
you wrote it -- so I doubt (might be wrong though) that something like JLS
would talk about compiler optimizations.

Regards

On Tue, Jan 17, 2012 at 11:17 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> 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)
>



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


More information about the Concurrency-interest mailing list