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

Vitaly Davidovich vitalyd at gmail.com
Wed Apr 17 13:20:54 EDT 2013


Yes, I don't expect that for println either, but I do in the scenarios that
Nathan and I described.

Sent from my phone
On Apr 17, 2013 1:15 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:

> On Wed, Apr 17, 2013 at 10:44 AM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> > I actually expect that the optimizer *would* do this transformation on
> plain
>
> I do not expect that, since println() interacts with the external
> world. Consider this program:
>
> Thread 1
> [1]    shared = 1;
> [2]    console.print("press enter to continue");
>
> Thread 2
> [3]    console.readLine();
> [4]    r = shared;
>
> If there is a causality from [2] to [3] in the physics world (the
> human user sees the prompt which drives him to press enter), isn't it
> reasonable to assume that [4] sees [1]? If we don't have that
> guarantee, how can we write programs that appear to be coherent to the
> outside world? Note that making [1] and [4] volatile or synchronized
> won't help, as long as there is not an edge from [2] to [3].
>
> Zhong Yu
>
> > fields (provided it doesn't break intra-thread semantics, of course)
> because
> > it's a perf gain.
> >
> > Don't know how much JIT can see through println as it ultimately calls
> into
> > runtime and OS functions, so I'd guess it doesn't know enough or simply
> > plays conservative here.  However, Nathan's point is still valid even if
> > example isn't necessarily the best one.  If you had "pure" java code
> instead
> > of an I/O call that took significant time to execute, the write would be
> > delayed.  I'm not sure why that matters though for benign data races.
> > Clearly if you need immediate visibility, you code for that specifically.
> >
> > On Apr 17, 2013 11:32 AM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:
> >>
> >> On Wed, Apr 17, 2013 at 1:38 AM, Nathan Reynolds
> >> <nathan.reynolds at oracle.com> wrote:
> >> > Couldn't JIT hoist the non-volatile writes out of the loop?
> >>
> >> Certainly, sorry if my statement sounds too absolute.
> >>
> >> > For example, the following code...
> >>
> >> But, is this a valid example? Can JMM really reorder around
> >> System.out.println()?
> >>
> >> > 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 | Architect | 602.333.9091
> >> > Oracle PSR Engineering | 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>
> >> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/d19170fa/attachment.html>


More information about the Concurrency-interest mailing list