On Tue, Sep 15, 2015 at 12:06 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote:
> > From: Yilong Li [mailto:yilong...@runtimeverification.com] > > Subject: Re: RV-Predict bugs > > > > True, but as Mark previously pointed out, no one cares. All that > happens > > > in that case is the object is redundantly created and then garbage > > > collected later; no damage. > > > No, it's not right. It's possible (although very unlikely) that this > method > > could return null and results in a null pointer exception later. > > Again, that cannot happen; see below. > > > Intra-thread semantics says that event 3 (the first read of the field > > hashCode) happens before event 4 (the second read of field hashCode) but > it > > has no effect on the value event 4 can see (because event 3 is also a > read > > rather than a write). > > You're mixing up inter- and intra-thread semantics and completely ignoring > the write to hashCode when the initially observed value is zero. > Intra-thread semantics require that operations occur in program order, so > the initial zero (or null) check results in a non-zero (or non-null) write > to the field of interest; control flow cannot be ignored here. If your > supposition were correct, a compiler (or CPU) would be free to migrate > actions dependent on a conditional block to a spot prior to that > conditional block - clearly that is nonsense. Nope, I know what I am doing. Let's first see what the expert says. Please check out the last section in this article ( http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.html) which starts with "let's break the code". Here, we are talking about T2 in the above example. The second read of the field hashCode is not control-flow-dependent on the first read (the zero-check). Again, intra-thread semantics introduces HB order between the event 3 and event 4. But it doesn't ensure that event 4 must see the same value as event 3. Yilong > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail and > its attachments from all computers. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
