Wiki Markup
Client-side locking entails guarding client code that uses some object X with the lock X uses to guard its own state. In order to use client-side locking, you must know what lock X uses.
Wiki Markup
If extending a class to add another atomic operation is fragile because it distributes the locking code for a class over multiple classes in an object hierarchy, client-side locking is even more fragile because it entails putting locking code for class C into classes that are totally unrelated to C. Exercise care when using client-side locking on classes that do not commit to their locking strategy.
...
The documentation of a class that supports client-side locking should explicitly state its applicability. For example, the class {{java.util.concurrent.ConcurrentHashMap<K,V>}} should not be used for client-side locking because its documentation \ [[API 2006|AA. References#API 06]\] states that:
However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with
Hashtablein programs that rely on its thread safety but not on its synchronization details.
...
Use of client-side locking is permitted only when the documentation of the class recommends it. For example, the documentation of the {{synchronizedList()}} wrapper method of {{java.util.Collections}} class \ [[API 2006|AA. References#API 06]\] states
In order to guarantee serial access, it is critical that all access to the backing list is accomplished through the returned list. It is imperative that the user manually synchronize on the returned list when iterating over it. Failure to follow this advice may result in non-deterministic behavior.
...
Noncompliant Code Example (Class Extension and Accessible Member Lock)
...
Goetz and colleagues describe the fragility of class extension for adding functionality to thread-safe classes \ [[Goetz 2006|AA. References#Goetz 06]\]:
Extension is more fragile than adding code directly to a class, because the implementation of the synchronization policy is now distributed over multiple, separately maintained source files. If the underlying class were to change its synchronization policy by choosing a different lock to guard its state variables, the subclass would subtly and silently break because it no longer used the right lock to control concurrent access to the base class's state.
...
| Code Block | ||
|---|---|---|
| ||
// This class could change its locking policy in the future,
// for example, if new non-atomic methods are added
class IPAddressList {
private final List<InetAddress> ips =
Collections.synchronizedList(new ArrayList<InetAddress>());
public List<InetAddress> getList() {
return ips; // No defensive copies required
// as visibility is package-private
}
public void addIPAddress(InetAddress address) {
ips.add(address);
}
}
class PrintableIPAddressList extends IPAddressList {
public void addAndPrintIPAddresses(InetAddress address) {
synchronized (getList()) {
addIPAddress(address);
InetAddress[] ia =
(InetAddress[]) getList().toArray(new InetAddress[0]);
// ...
}
}
}
|
...
If the {{IPAddressList}} class were modified to use block synchronization on a private final lock object, as recommended by rule [LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code], the {{PrintableIPAddressList}} subclass would silently break. Moreover, if a wrapper such as {{Collections.synchronizedList()}} were used, it would be difficult for a client to determine the type of the class being wrapped to extend it \ [[Goetz 2006|AA. References#Goetz 06]\].
Compliant Solution (Composition)
...
| Code Block | ||
|---|---|---|
| ||
// Class IPAddressList remains unchanged
class PrintableIPAddressList {
private final IPAddressList ips;
public PrintableIPAddressList(IPAddressList list) {
this.ips = list;
}
public synchronized void addIPAddress(InetAddress address) {
ips.addIPAddress(address);
}
public synchronized void addAndPrintIPAddresses(InetAddress address) {
addIPAddress(address);
InetAddress[] ia =
(InetAddress[]) ips.getList().toArray(new InetAddress[0]);
// ...
}
}
|
Wiki Markup PrintableIPAddressList}} class to use its own intrinsic lock independent of the underlying list class's lock. The underlying collection lacks a requirement for thread-safety because the {{PrintableIPAddressList}} wrapper prevents direct access to its methods by publishing its own synchronized equivalents. This approach provides consistent locking even when the underlying class changes its locking policy in the future \ [[Goetz 2006|AA. References#Goetz 06]\].
Risk Assessment
Using client-side locking when the thread-safe class fails to commit to its locking strategy can cause data inconsistencies and deadlock.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
LCK11-J | low | probable | medium | P4 | L3 |
Bibliography
...
[[API 2006AA. References#API 06] ] | Class | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="495fc4a8-5b0c-46f6-bd0b-559b2290fb48"><ac:plain-text-body><![CDATA[ | [[JavaThreads 2004AA. References#JavaThreads 04] ] | 8.2, Synchronization and Collection Classes | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="cd7176de-2caa-493a-bcf1-79658c764742"><ac:plain-text-body><![CDATA [ [[Goetz 2006AA. References#Goetz 06] ] | 4.4.1, Client-side Locking; 4.4.2, Composition; and 5.2.1, | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="298ebd70-9a40-4771-b558-be1852f4d50a"><ac:plain-text-body><! [CDATA[ [[Lee 2009AA. References#Lee 09]] | Map & Compound Operation ]]></ac:plain-text-body></ac:structured-macro> |
...
LCK10-J. Do not use incorrect forms of the double-checked locking idiom 08. Locking (LCK) 09. Thread APIs (THI)