commit-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #2945] Incorrect synchronization in java.util.logging.ErrorManager


From: nobody
Subject: [bug #2945] Incorrect synchronization in java.util.logging.ErrorManager
Date: Mon, 20 Oct 2003 06:17:45 -0400
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a) Gecko/20020610

=================== BUG #2945: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=2945&group_id=85

Changes by: Sascha Brawer <address@hidden>
Date: Mon 10/20/2003 at 10:17 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Duplicate
      Dependent Bugs |                           | 2944




=================== BUG #2945: FULL BUG SNAPSHOT ===================


Submitted by: davidholmes             Project: classpath                    
Submitted on: Wed 03/26/2003 at 16:28
Severity:  5 - Major                  Resolution:  Duplicate                
Assigned to:  None                    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: Wed 06/11/2003 at 17:39       By: mkoch
Duplicate of #2944


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=2945&group_id=85

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]