[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #2944] Incorrect synchronization in java.util.logging.ErrorManager
From: |
nobody |
Subject: |
[bug #2944] Incorrect synchronization in java.util.logging.ErrorManager |
Date: |
Tue, 21 Oct 2003 01:41:03 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a) Gecko/20020610 |
=================== BUG #2944: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=2944&group_id=85
Changes by: Sascha Brawer <address@hidden>
Date: Tue 10/21/2003 at 05:41 (GMT)
What | Removed | Added
---------------------------------------------------------------------------
Resolution | None | Fixed
Status | Accepted | Closed
------------------ Additional Follow-up Comments ----------------------------
(Cited e-mail; From: David Holmes; To: Sascha Brawer)
Yes it does.
This particular usage of the double-check idiom is about the safest you could
have as the flag is the only bit of data involved. My remarks about the new JMM
were more a commentary on the general use of double-checked-locking, where
typically the flag protects access to some data and you're not guaranteed to
see the data even if you see the flag under the old JMM. In this case there is
no data, so this is correct under both old and new JMM - so you could tone down
the comments a little if you like.
=================== BUG #2944: FULL BUG SNAPSHOT ===================
Submitted by: davidholmes Project: classpath
Submitted on: Wed 03/26/2003 at 16:27
Severity: 5 - Major Resolution: Fixed
Assigned to: brawer Status: Closed
Platform Version: None
Summary: Incorrect synchronization in java.util.logging.ErrorManager
Original Submission: ErrorManager.error is a method that should only be
executed once. To achieve this a field is set so that subsequent invocations
return immediately. Synchronization is needed to ensure that only one thread
successfully makes the single call that sets the field.
To avoid synchronization on every call to error() a form of double-checked
locking is used. However, the double-checked locking idiom does not work unless
combined with the use of volatile variables (and even then that depends on the
usage until the new Java Memory Model is finalised and adopted).
In this case the everUsed field must be marked as volatile so that all threads
are guaranteed to see the value set in it by the thread that successfully
acquires the lock.
A second issue is that the lock used is that of the ErrorManager class object.
This forces threads using different ErrorManager objects to serialize through
the same lock. This is unnecessary. The lock used can simply be that of 'this',
or a private Object used solely for locking purposes.
Follow-up Comments
*******************
-------------------------------------------------------
Date: Tue 10/21/2003 at 05:41 By: brawer
(Cited e-mail; From: David Holmes; To: Sascha Brawer)
Yes it does.
This particular usage of the double-check idiom is about the safest you could
have as the flag is the only bit of data involved. My remarks about the new JMM
were more a commentary on the general use of double-checked-locking, where
typically the flag protects access to some data and you're not guaranteed to
see the data even if you see the flag under the old JMM. In this case there is
no data, so this is correct under both old and new JMM - so you could tone down
the comments a little if you like.
-------------------------------------------------------
Date: Tue 10/21/2003 at 05:38 By: brawer
(Cited e-mail; From: Sascha Brawer; To: David Holmes)
Would the following patch solve the problem? I'm assuming that VM implementors
are aware of the revised memory model.
[patch that got checked into cvs on 2003-10-21]
-------------------------------------------------------
Date: Wed 03/26/2003 at 16:37 By: davidholmes
Can someone please delete the duplicate reports 2945, 2946 and 2947.
The bug submission system seems to have a glitch with browser refreshes. After
submitting the bug I went "back" to the bug list page. Browser says the page
has expired and will "repost" the form (I should have guessed what was
happening). I go back to the bug list page but my bug has been resubmitted a
second time. I look in another bug report and go "back" and the same thing
happens. Finally I realized what was going on. Backing out to the top-level
seemed to fix this.
Sorry about that. This site seems to have a number of navigation problems - eg.
with regard to logging.
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=2944&group_id=85
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/