tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 49778] Inconsistent synchronization in SimplePool.java
Date Fri, 20 Aug 2010 12:05:09 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778

--- Comment #5 from Daniel Luo <fslzdd@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message