Sorry about the vague explanation. But the actual reasons are not the point here. The only thing matters is the Java memory model. And the article I refer to explain exactly why and how this can happen.
I agree that such non-thread-safe lazy initialization rarely causes problem. But, guys, please take a look at other issues I reported. There are much more interesting concurrency bugs. I am reporting these minor issues only because they are clearly bugs. Mark, if you have a specific concurrency issue you would like to investigate, the best way is to run RV-Predict against the code that once revealed the problem. Even if the failure occurs rarely, RV-Predict may be able to identify the cause for you. I get all these race reports by running RV-Predict against the test suite so if the small unit test doesn't exercise the problematic code enough you may not get the specific answer you are looking for. Yilong On Sun, Sep 13, 2015 at 1:30 PM, Mark Thomas <ma...@apache.org> wrote: > On 13/09/2015 19:02, Rémy Maucherat wrote: > > 2015-09-13 18:45 GMT+02:00 Mark Thomas <ma...@apache.org>: > > > >> 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>> 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. > >> > >> > > As far as I am concerned, I would prefer batch closing these "issues" > > nobody ever had. > > That is very tempting. > > Looking at the articles by the folks that are the experts in the field > (i.e. the authors of JSR-133) it looks like the issues raised are valid > - even if we don't see then very often / at all. Despite that, I'd be a > lot happier with a clearer explanation of what can go wrong and why/how. > > On the plus side, the issues I've looked at so far have provided > opportunities for clean-up in trunk. > > I'm hoping (but haven't look at all of them yet) that at least one of > these reports is going to identify the root cause of one of those hard > to reproduce / hard to track down concurrency issues. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
