On 13/09/2015 18:02, Yilong Li wrote: > Hi Mark, > > Atomicity is just one aspect of concurrency. You have to take visibility > (i.e., when the effects of one thread can be seen by another) and > ordering (i.e., when actions in one thread can be seen to occur out of > order with respect to another) into account when writing concurrent > code. So it's generally a good idea to remove any data race. > > In short, when st_200 is in a data race, the two reads of st_200 can > happen out-of-order because of many tricky reasons (e.g., instruction > reordering, caching effect, etc). Sequential consistency is only > guaranteed for data-race-free program. Here is a more detailed article > by Jeremy Manson explaining such non-thread-safe lazy > initialization: > http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.html. > Jeremy is one of the authors of JMM.
While I'm prepared to believe there is a problem here I'd be a lot happier with a clear explanation of what the problem is rather than some vague hand-waving under the heading of 'tricky reasons'. What I am looking for is a step by step description of how code like this can go wrong with references to the JMM to explain why the behaviour that causes the problem (e.g. re-ordering) is permitted. I have yet to find such a description. Mark > > Yilong > > On Sun, Sep 13, 2015 at 9:45 AM, Mark Thomas <ma...@apache.org > <mailto:ma...@apache.org>> wrote: > > Yilong, > > You need to be subscribed to the dev list in order to post to it. > > On 13/09/2015 14:08, Yilong Li wrote: > > Hi Mark, > > > > On Sun, Sep 13, 2015 at 4:08 AM, Mark Thomas <ma...@apache.org > <mailto:ma...@apache.org> > > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> wrote: > > > > Please do not add any more RV-Predict bug reports to Bugzilla until > the > > current set have been evaluated. To be honest it would have been > better > > if you had paused after adding 58367-58379. > > > > > > I am going to stop here because these are all the bugs reported by > > RV-Predict in one run of the entire test suite. > > OK. Lets resolve these and then see where we stand. > > <snip/> > > > BZ 58367 is clearly a data race bug that is harmful. So are 58368 & > > 58369. Consider the following code: > > > > if(st_200 == null ) { > > st_200 = sm.getString("sc.200"); > > } > > return st_200; > > > > Since the field st_200 is in a data race, it's legal under JMM (Java > > memory model) for this method to return null even when the first read of > > st_200 returns a non-null value. > > How? Writes to references are atomic. sm.getString("sc.200"); is always > going to return the same non-null String so once a thread has seen a > non-null value for st_200 how can it later see a null one? > > > If you want it to be thread-safe, you > > have to ensure there is at most one memory read: > > > > String s = st_200; > > if(s == null ) { > > st_200 = s = sm.getString("sc.200"); > > } > > return s; > > > > Only in this way, the data race becomes benign. > > I can see this would help if something was changing the value of st_200 > from non-null to null, but nothing is. > > Mark > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
