[concurrency-interest] On A Formal Definition of 'Data-Race'

Vitaly Davidovich vitalyd at gmail.com
Wed Apr 17 12:55:38 EDT 2013


This is called write combining in Intel parlance (maybe not just them, not
sure).  However, in the example shown, it's not just wasteful stores but
the fact that the store is loop invariant in a way - the loop is counted
and no early returns from it.
On Apr 17, 2013 12:27 PM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
wrote:

>  If I have my details correct, the Intel x86 processor will fuse 2
> back-to-back stores into 1 store if they are for the same address.  JIT has
> a lot more information about the program than the processor and might
> "fuse" stores to the same field.  The loop hoisting example is one such
> case.
>
> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Architect |
> 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>  On 4/17/2013 6:32 AM, oleksandr otenko wrote:
>
> I am not sure what you are saying.
>
> I am only saying that moving the write out of the loop is possible only if
> we can prove it is not used inside the loop. Multiple writes are fused in
> exactly the same way as multiple reads are fused. Elimination is a form of
> reordering.
>
> Alex
>
> On 17/04/2013 14:25, Gregg Wonderly wrote:
>
> Actually the compiler doesn't do that for non-volatile access, as I've
> been going on about with the loop exit hoisting example.  This
> transformation is exactly the kind of thing that I'd expect to see happen,
> and this is the "unexplainable behavior" that will create alarm, because
> mutations of "shared" are not visible, except a loop exit.
>
> Gregg Wonderly
>
> On 4/17/2013 5:18 AM, oleksandr otenko wrote:
>
> You need to prove System.out.println isn't using shared.
>
> Alex
>
> On 17/04/2013 07:38, Nathan Reynolds wrote:
>
> Couldn't JIT hoist the non-volatile writes out of the loop?  For example,
> the
> following code...
>
> for (i = 0; i < 1_000_000_000; i++)
> {
>     System.out.println(i);
>     shared = 2 * i;
> }
>
> ... could be transformed into ...
>
> for (i = 0; i < 1_000_000_000; i++)
> {
>     System.out.println(i);
> }
>
> shared = 2 * 1_000_000_000;
>
> ... If so, then the non-volatile write may not happen for a very long
> time.
>
> Nathan Reynolds
> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds><http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>
> | Architect | 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/><http://psr.us.oracle.com/>| Server Technology
> On 4/16/2013 10:27 PM, Zhong Yu wrote:
>
> On Tue, Apr 16, 2013 at 8:51 PM, thurstonn<thurston at nomagicsoftware.com><thurston at nomagicsoftware.com>
> wrote:
>
> Vitaly Davidovich wrote
>
> The code works as-is.
>
> Absolutely.  volatile is not needed for correctness
>
> Vitaly Davidovich wrote
>
> Why?
>
> Well, for performance reasons given the 'undefined/indefinite' visibility
> of
> #hash to other threads.
> At least according to the JMM (which has nothing to say about CPU cache
> coherency), it is *possible* that each distinct thread that invoked
> #hashCode() *could* result in a recalculation of the hash.
>
> In practice though, application threads contain very frequent
> synchronization actions, or other operations that force VM to
> flush/reload. So it won't take very long for any non-volatile write in
> one thread to become visible to other threads.
>
> Imagine a long-lived Map<String, ?>; and many threads accessing the map's
> keyset and for some unknown reason invoking #hashCode() on each key.
> If #hash was declared volatile, although there is no guarantee that #hash
> would only be calculated once, it is guaranteed that once a write to main
> memory was completed, every *subsequent* (here meaning after the write to
>
> In JMM though, we cannot even express this guarantee. Say we have
> threads T1...Tn, each thread Ti burns `i` seconds CPU time first, then
> volatile-reads #hash, and if it's 0, calculates and volatile-writes
> #hash which takes 100 ns. We can find no guarantee from JMM that
> there's only one write; it's legal that every thread sees 0 from the
> volatile read.
>
> Zhong Yu
>
> main memory) read no matter from which thread would see #hash != 0 and
> therefore skip the calculation.
>
>
>
> Vitaly Davidovich wrote
>
> String is too high profile (especially
> hashing it) to do the "naive" thing.
>
> Nothing wrong with being naive; naive can be charming.
>
>
> Vitaly Davidovich wrote
>
> Also, some architectures pay a
> penalty for volatile loads and you'd incur that each time.
>
> Fair point; the JDK authors only get one shot and they can't assume that
> volatile reads are cheap
>
>
>
>
>
> --
> View this message in context:
> http://jsr166-concurrency.10961.n7.nabble.com/On-A-Formal-Definition-of-Data-Race-tp9408p9466.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/7233e9c9/attachment.html>


More information about the Concurrency-interest mailing list