On Tue, Sep 15, 2015 at 11:32 AM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote:
> > From: Yilong Li [mailto:yilong...@runtimeverification.com] > > Subject: Re: RV-Predict bugs > > > Well, it is the problem (at least part of it) because JLS says > "Informally, > > a read *r* is allowed to see the result of a write *w* if there is no > > *happens-before* ordering to prevent that read." In this case, there is > no > > HB ordering preventing event 3 to read the initial null value put by JVM. > > 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. > > > But consider the following hashcode example: > > public int hashCode() { > > if (hashCode == 0) { > > hashCode = computeHashCode(); // no object creation involved > > } > > return hashCode; > > } > > > There is no object initialization/publication involved at all but the > > problem still exists: this method could return 0 even if the if-statement > > sees a non-zero value. > > No, it can't (unless computeHashCode() returns a zero, which presumably it > won't). This is all action within a single thread, and as such must obey > intra-thread semantics (i.e., statements are executed in control flow > order). > Yes, it can. You probably misunderstand intra-thread semantics. 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). 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 > >
