Page History

According to Goetz and colleagues \[[Goetz 06|AA. Java References#Goetz 06]\]:

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

...

.

...

While client-side locking is acceptable if the thread-safe class commits to its locking strategy and clearly documents it, Goetz et al.cautions against its misuse \[[Goetz 06|AA. Java References#Goetz 06]\] caution against its misuse:

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 does supportsupports client-side locking should explicitly state its applicability. For instanceexample, the class {{java.util.concurrent.ConcurrentHashMap<K,V>}} should not be used for client-side locking, because its documentation states \[[API 06|AA. Java References#API 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 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.

Note that this advice is compliant consistent with CON06-J. Do not synchronize on a collection view if the backing collection is accessible when the backing list is inaccessible from a caller that can potentially inflict harmto an untrusted client.

Noncompliant Code Example (

...

Intrinsic Lock)

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

...

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

...

If class Book changes its synchronization policy in the future, the BookWrapper class's locking strategy might silently break. For instance, the Bookwrapper class's locking strategy will definitely break breaks if Book is modified to use a private final lock object, as recommended by CON04-J. Use private final lock objects to synchronize classes that may interact with untrusted code. This is because threads that call BookWrapper.getDueDate() may perform operations on the thread-safe Book using its new locking policy. However, threads that call method renew() will always synchronize on the intrinsic lock of the Book instance. Consequently, the implementation will use two different locks.

Compliant Solution (

...

Private Final Lock Object)

This compliant solution uses a private final lock object and synchronizes all its methods using this lock.

public final class BookWrapper {
  private final Book book;
  private final Object lock = new Object();

  BookWrapper(Book book) {
    this.book = book;
  }

  public void issue(int days) {
    synchronized(lock) {
      book.issue();
    }
  }

  public Calendar getDueDate() {
    synchronized(lock) {
      return book.getDueDate();
    }
  }

  public void renew() {
    synchronized(lock) {
      if (book.getDueDate().after(Calendar.getInstance())) {
        throw new IllegalStateException("Book overdue");
      } else {
        book.issue(14); // Issue book for 14 days
      }
    }
  }
}

Wiki MarkupConsequently, the {{BookWrapper}} The BookWrapper class's locking strategy is now independent of the locking policy of the {{Book}} instance. This solution incurs a very small performance penalty but the resulting code is much more robust \[[Goetz 06|AA. Java References#Goetz 06]\].

Noncompliant Code Example (

...

Class Extension and Accessible Member Lock)

Goetz etand al.colleagues describe the fragility of class extension for adding functionality to thread-safe classes \[[Goetz 06|AA. Java References#Goetz 06]\]:

...