tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 49778] Inconsistent synchronization in
Date Thu, 19 Aug 2010 23:11:58 GMT

--- Comment #3 from Chuck Caldarale <> 2010-08-19 19:11:53
EDT ---
(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.

> > 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).

> 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

> > - 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.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message