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:39:32 GMT

--- Comment #4 from Sebb <> 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:
------- 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