[concurrency-interest] Question about re-ordering

Khilan Gudka khilan at doc.ic.ac.uk
Wed Jan 18 06:05:47 EST 2012


Hi

So is this true for all native method calls? That they will never be
re-ordered?

--
Khilan Gudka
PhD Student
Department of Computing
Imperial College London
http://www.doc.ic.ac.uk/~khilan/



On 18 January 2012 05:03, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> The JLS does mention compiler (and microprocessor) optimizations:
>
> http://java.sun.com/docs/books/jls/third_edition/html/memory.html
>
> The JLS also says that the execution of data race free programs is
> sequentially consistent, which rules out any observable reordering of
> statements in the body of a method.
>
> Joe
>
> On Tue, Jan 17, 2012 at 8:19 PM, Vitaly Davidovich wrote:
>
>> 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 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 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120118/8b42d30e/attachment.html>


More information about the Concurrency-interest mailing list