https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #4 from Sebb <s...@apache.org> 2010-08-19 19:39:28 EDT --- (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. -- 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
