Page History

...

While client-side locking is acceptable ifwhen the thread-safe class commits to its locking strategy and clearly documents it, Goetz and colleagues caution against its misuse \[[Goetz 2006|AA. Bibliography#Goetz 06]\]:

...

... 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 Hashtable in programs that rely on its thread safety but not on its synchronization details.

In general, useUse 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 states \[[API 2006|AA. Bibliography#API 06]\] 

...

This noncompliant code example uses a thread-safe Book class that cannot be refactored. Refactoring might be impossible, for example, if when the source code is not available unavailable for review or if when the class is part of a general library that cannot be extended.

final class Book {
  // Could change its locking policy in the future to use private final locks
  private final String title;
  private Calendar dateIssued;
  private Calendar dateDue;

  Book(String title) {
    this.title = title;
  }

  public synchronized void issue(int days) {
    dateIssued = Calendar.getInstance();
    dateDue = Calendar.getInstance();
    dateDue.add(dateIssued.DATE, days);
  }

  public synchronized Calendar getDueDate() {
    return dateDue;
  }
}

This class does not fails to commit to its locking strategy (that is, it reserves the right to change its locking strategy without notice). Furthermore, it does not fails to document that callers can safely use client-side locking. The client class BookWrapper client class uses client-side locking in the renew() method by synchronizing on a Book instance.

...

If the Book class changes its synchronization policy in the future, the BookWrapper class's locking strategy might silently break. For instance, the Bookwrapper class's locking strategy breaks would break if Book is were modified to use 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 BookWrapper class's locking strategy breaks would break because threads that call BookWrapper.getDueDate() may perform operations on the thread-safe Book using its new locking policy. However, threads that call the renew() method will would always synchronize on the intrinsic lock of the Book instance. Consequently, the implementation will would use two different locks.

Compliant Solution (Private Final Lock Object)

...

If the {{IPAddressList}} class iswere 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 willwould silently break. Moreover, if a wrapper such as {{Collections.synchronizedList()}} iswere used, it iswould be difficult for a client to determine the type of the class being wrapped to extend it \[[Goetz 2006|AA. Bibliography#Goetz 06]\].

...

This compliant solution wraps an object of the IPAddressList class and provides synchronized accessors that can be used to manipulate the state of the object.

...

In this case, composition allows the {{PrintableIPAddressList}} class to use its own intrinsic lock independent of the underlying list class's lock. The underlying collection doeslacks nota needrequirement to befor thread-safesafety because the {{PrintableIPAddressList}} wrapper prevents direct access to its methods by publishing its own synchronized equivalents. This approach provides consistent locking even ifwhen the underlying class changes its locking policy in the future \[[Goetz 2006|AA. Bibliography#Goetz 06]\].

...

Using client-side locking when the thread-safe class does not fails to commit to its locking strategy can cause data inconsistencies and deadlock.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

...

...