[concurrency-interest] Question about re-ordering

David Holmes davidcholmes at aapt.net.au
Tue Jan 17 18:26:15 EST 2012


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



More information about the Concurrency-interest mailing list