From dev-return-108563-apmail-tomcat-dev-archive=tomcat.apache.org@tomcat.apache.org Fri Aug 20 12:05:53 2010 Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 64737 invoked from network); 20 Aug 2010 12:05:53 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Aug 2010 12:05:53 -0000 Received: (qmail 11607 invoked by uid 500); 20 Aug 2010 12:05:52 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 11082 invoked by uid 500); 20 Aug 2010 12:05:49 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 11073 invoked by uid 99); 20 Aug 2010 12:05:48 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Aug 2010 12:05:48 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Aug 2010 12:05:31 +0000 Received: from thor.apache.org (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o7KC59U8016843 for ; Fri, 20 Aug 2010 12:05:09 GMT Received: (from daemon@localhost) by thor.apache.org (8.13.8+Sun/8.13.8/Submit) id o7KC599m016842; Fri, 20 Aug 2010 08:05:09 -0400 (EDT) Date: Fri, 20 Aug 2010 08:05:09 -0400 (EDT) Message-Id: <201008201205.o7KC599m016842@thor.apache.org> From: bugzilla@apache.org To: dev@tomcat.apache.org Subject: DO NOT REPLY [Bug 49778] Inconsistent synchronization in SimplePool.java X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Tomcat 6 X-Bugzilla-Component: Catalina X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: fslzdd@gmail.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dev@tomcat.apache.org X-Bugzilla-Target-Milestone: default X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: https://issues.apache.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org https://issues.apache.org/bugzilla/show_bug.cgi?id=49778 --- Comment #5 from Daniel Luo 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