https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #5 from Daniel Luo <fsl...@gmail.com> 2010-08-20 08:05:04 EDT --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > > > > > Since the lock is dropped immediately after retrieving > > > > the value, the value may change well before any decisions > > > > can be made based on the value. This is completely > > > > independent of the JVM memory model. > > > > > > True, but irrelevant here. > > > > No, it's pretty much the only relevant part. If the value can change after > > retrieval but before usage, you still don't have the current value. If > > decisions are to be made based on the value, the lock must be maintained > > across > > the retrieval and the decision. If no decisions are to be made on the > > value, > > then it doesn't matter if it's current, since it could change at any time. > > What I meant was that it was irrelevant to the original bug report, which only > pointed out that the value might be arbitrarily stale. > > > > > If you want to insure that getCount always retrieves the > > > > current value, the field must be flagged as volatile > > > > > > Not strictly true. > > > > Agreed; "must" was too strong. Flagging it as volatile is the least > > expensive > > way of insuring that the various compilers involved don't over-optimize the > > reference. Using a synchronization block is more expensive (although much > > cheaper in current JVMs than it used to be). > > Not necessarily the least expensive here. Adding volatile to the field affects > all accesses, including the ones currently protected by synch. blocks. > > > > Since the other accesses need to use synchronisation, it > > > makes sense to use synchronisation here too. > > > > No, the other accesses are mutators; the reader of a simple value such as an > > int needs no synchronization - unless it's going to base some action on the > > value. > > If it is not going to use the value, why read it in the first place? > > > > > - but that does nothing to prevent it > > > > changing the moment after it has been referenced. > > > > > > Again true, but irrelevant. > > > > Not at all irrelevant; the value retrieved is no longer current, which was > > your > > stated concern. > > It was not my bug report... > AIUI the original author was only concerned that the value might be stale. > > For example, if the count is to be displayed, it might not matter if the value > is not 100% current, but it would matter if the value is arbitrarily stale. > > If the current exact value is needed, then of course the code needs to be part > of the synch. block unless it is somehow known that the value cannot be > changed > by other threads at that point. Sebb totally understands my willing. This bug report is only about reading current field without holding a lock can return a stale or inconsistent value, even for integer. Whether the future usage after retrieval can see the update-to-date value is not my concern of this bug report. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
