-
Type:
Improvement
-
Status: Closed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
This task involves investigating the benefits (and drawbacks) of using internal instance or static members for synchronization. Java: Concurrency In Practice (p. 61) states:
There are advantages to using a private lock object instead of an object's intrinsic lock [ for example synchronized (this) ] (or any other publicly accessible lock). Making the lock object private encapsulates the lock so that client code cannot acquire it, whereas a publicly accessible lock allows client code to participate in its synchronization policy---correctly or incorrectly. Clients that improperly acquire another object's lock could cause liveness problems, and verifying that a publicly accessible lock is properly used requires examining the entire program rather than a single class.
As part of this task, a consistent policy towards intrinsic locks (locking on this ) and locking on .class es should be determined, and the code should be made to consistently utilize either intrinsic/public locks or private locks.
- depends on
-
FACES-3279 Add feature to encapsulate thread-safe double-checked locking intialization
-
- Closed
-