Page History

A consistent locking policy guarantees that multiple threads cannot simultaneously access or modify shared data. When two or more operations must be performed as a single atomic operation, a consistent locking policy must be implemented using some form of locking, such as a mutex. In the absence of such a policy, the code is susceptible to race conditions.

When presented with a set of operations, where each is guaranteed to be atomic, it is tempting to assume that a single operation consisting of individually-atomic operations is guaranteed to be collectively atomic without additional locking. A grouping of calls to such methods requires additional synchronization for the group.

Compound operations on shared variables are also non-atomic. See rule CON42 CON07-C. Ensure that compound operations on shared variables are atomic for more information.

Noncompliant Code Example

This noncompliant code example wraps references to BigInteger objects within thread-safe AtomicReference objects.

 

final class Adder {   private final AtomicReference<BigInteger> first;   private final AtomicReference<BigInteger> second;     public Adder(BigInteger f, BigInteger s) {     first  = new AtomicReference<BigInteger>(f);     second = new AtomicReference<BigInteger>(s);   }     public void update(BigInteger f, BigInteger s) { // Unsafe     first.set(f);     second.set(s);   }     public BigInteger add() { // Unsafe     return first.get().add(second.get());   } }

 

AtomicReference is an object reference that can be updated atomically. However, operations that combine more than one atomic reference are non-atomic. In this noncompliant code example, one thread may call update() while a second thread may call add(). This might cause the add() method to add the new value of first to the old value ofsecond, yielding an erroneous result.

Compliant Solution (Method Synchronization)

This compliant solution declares the update() and add() methods synchronized to guarantee atomicity.

Noncompliant Code Example (synchronizedList())

This noncompliant code example uses a java.util.ArrayList<E> collection, which is not thread-safe. However, the example uses Collections.synchronizedList as a synchronization wrapper for the ArrayList. It subsequently uses an array, rather than an iterator, to iterate over the ArrayList to avoid aConcurrentModificationException.

Individually, the add() and toArray() collection methods are atomic. However, when called in succession (as shown in the addAndPrintIPAddresses() method), there is no guarantee that the combined operation is atomic. The addAndPrintIPAddresses() method contains a race condition that allows one thread to add to the list and a second thread to race in and modify the list before the first thread completes. Consequently, the addressCopy array may contain more IP addresses than expected.

Compliant Solution (Synchronized Block)

The race condition can be eliminated by synchronizing on the underlying list's lock. This compliant solution encapsulates all references to the array list within synchronized blocks.

This technique is also called client-side locking [Goetz 2006] because the class holds a lock on an object that might be accessible to other classes. Client-side locking is not always an appropriate strategy; see rule LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy for more information.

This code does not violate rule LCK04-J. Do not synchronize on a collection view if the backing collection is accessible because, while it does synchronize on a collection view (thesynchronizedList result), the backing collection is inaccessible and consequently cannot be modified by any code.

Note that this compliant solution does not actually use the synchronization offered by Collections.synchronizedList(). If no other code in this solution used it, it could be eliminated.

Noncompliant Code Example (synchronizedMap())

This noncompliant code example defines the KeyedCounter class that is not thread-safe. Although the HashMap is wrapped in a synchronizedMap(), the overall increment operation is not atomic [Lee 2009].

Compliant Solution (Synchronization)

This compliant solution ensures atomicity by using an internal private lock object to synchronize the statements of the increment() and getCount() methods.

This compliant solution avoids using Collections.synchronizedMap() because locking on the unsynchronized map provides sufficient thread-safety for this application. RuleLCK04-J. Do not synchronize on a collection view if the backing collection is accessible provides more information about synchronizing on synchronizedMap() objects.

Compliant Solution (ConcurrentHashMap)

The previous compliant solution is safe for multithreaded use but does not scale because of excessive synchronization, which can lead to decreased performance.

The ConcurrentHashMap class used in this compliant solution provides several utility methods for performing atomic operations and is often a good choice for algorithms that must scale [Lee 2009].

Note that this compliant solution still requires synchronization, because without it, the test to prevent overflow and the increment will not happen atomically, so two threads callingincrement() can still cause overflow. The synchronization block is smaller, and does not include the lookup or addition of new values, so it has less of an impact on performance as the previous compliant solution.

According to Section 5.2.1., "ConcurrentHashMap" of the work of Goetz and colleagues [Goetz 2006]:

ConcurrentHashMap, along with the other concurrent collections, further improve on the synchronized collection classes by providing iterators that do not throwConcurrentModificationException, as a result eliminating the need to lock the collection during iteration. The iterators returned by ConcurrentHashMap are weakly consistent instead of fail-fast. A weakly consistent iterator can tolerate concurrent modification, traverses elements as they existed when the iterator was constructed, and may (but is not guaranteed to) reflect modifications to the collection after the construction of the iterator.

Note that methods such as ConcurrentHashMap.size() and ConcurrentHashMap.isEmpty() are allowed to return an approximate result for performance reasons. Code should avoid relying on these return values when exact results are required.

stores two integers atomically. It also provides atomic methods to obtain their sum and product. All methods are locked with the same mutex to provide their atomicity.

#include <threads.h>
#include <stdio.h>
#include <stdbool.h>
 
static int a = 0;
static int b = 0;
mtx_t lock;
 
bool init_mutex(int type) {
  /* Validate type */
  if (thrd_success != mtx_init(&lock, type)) {
    return false;  /* Report error */
  }
  return true;
}

void set_values(int new_a, int new_b) {
  if (thrd_success != mtx_lock(&lock)) {
    /* Handle error */
  }
  a = new_a;
  b = new_b;
  if (thrd_success != mtx_unlock(&lock)) {
    /* Handle error */
  }
}

int get_sum(void) {
  if (thrd_success != mtx_lock(&lock)) {
    /* Handle error */
  }
  int sum = a + b;
  if (thrd_success != mtx_unlock(&lock)) {
    /* Handle error */
  }
  return sum;
}
  
int get_product(void) {
  if (thrd_success != mtx_lock(&lock)) {
    /* Handle error */
  }
  int product = a * b;
  if (thrd_success != mtx_unlock(&lock)) {
    /* Handle error */
  }
  return product;
}

/* Can be called by multiple threads */
void multiply_monomials(int x1, int x2) {
  printf("(x + %d)(x + %d)\n", x1, x2);
  set_values( x1, x2);
  printf("= x^2 + %dx + %d\n", get_sum(), get_product());
}

Unfortunately, the multiply_monomials() function is still subject to race conditions, despite relying exclusively on atomic function calls. It is quite possible for get_sum() and get_product() to work with different numbers than the ones that were set by set_values(). It is even possible for get_sum() to operate with different numbers than get_product().

Compliant Solution

This compliant solution locks the multiply_monomials() function with the same mutex lock that is used by the other functions. For this code to work, the mutex must be recursive. This is accomplished by making it recursive in the init_mutex() function.

#include <threads.h>
#include <stdio.h>
#include <stdbool.h>

extern void set_values(int, int);
extern int get_sum(void);
extern int get_product(void);

mtx_t lock;
 
bool init_mutex(int type) {
  /* Validate type */
  if (thrd_success != mtx_init(&lock, type | mtx_recursive)) {
    return false;  /* Report error */
  }
  return true;
}

/* Can be called by multiple threads */
void multiply_monomials(int x1, int x2) {
  if (thrd_success != mtx_lock(&lock)) {
    /* Handle error */
  }
  set_values( x1, x2);
  int sum = get_sum();
  int product = get_product();
  if (thrd_success != mtx_unlock(&lock)) {
    /* Handle error */
  }

  printf("(x + %d)(x + %d)\n", x1, x2);
  printf("= x^2 + %dx + %d\n", sum, product);
}

Noncompliant Code Example

Function chaining is a useful design pattern for building an object and setting its optional fields. The output of one function serves as an argument (typically the last) in the next function. However, if accessed concurrently, a thread may observe shared fields to contain inconsistent values. This noncompliant code example demonstrates a race condition that can occur when multiple threads can variables with no thread protection.

#include <threads.h>
#include <stdio.h>

typedef struct currency_s {
  int quarters;
  int dimes;
  int nickels;
  int pennies;
} currency_t;
 
currency_t *set_quarters(int quantity, currency_t *currency) {
  currency->quarters += quantity;
  return currency;
}
currency_t *set_dimes(int quantity, currency_t *currency) {
  currency->dimes += quantity;
  return currency;
} 
currency_t *set_nickels(int quantity, currency_t *currency) {
  currency->nickels += quantity;
  return currency;
}
currency_t *set_pennies(int quantity, currency_t *currency) {
  currency->pennies += quantity;
  return currency;
}
 
int init_45_cents(void *currency) {
  currency_t *c = set_quarters(1, set_dimes(2, currency));
  /* Validate values are correct */
  return 0;
}
int init_60_cents(void* currency) {
  currency_t *c = set_quarters(2, set_dimes(1, currency));
  /* Validate values are correct */
  return 0;
}
 
int main(void) {
  thrd_t thrd1;
  thrd_t thrd2;
  currency_t currency = {0, 0, 0, 0};
 
  if (thrd_success != thrd_create(&thrd1, init_45_cents, &currency)) {
    /* Handle error */
  }
  if (thrd_success != thrd_create(&thrd2, init_60_cents, &currency)) {
    /* Handle error */
  }
  if (thrd_success != thrd_join(thrd1, NULL)) {
    /* Handle error */
  }
  if (thrd_success != thrd_join(thrd2, NULL)) {
    /* Handle error */
  }
 
  printf("%d quarters, %d dimes, %d nickels, %d pennies\n",
         currency.quarters, currency.dimes, currency.nickels, currency.pennies);
  return 0;
}

In this noncompliant code example, the program constructs a currency struct and starts two threads that use method chaining to set the optional values of the structure. This example code might result in the currency struct being left in an inconsistent state, for example, with two quarters and one dime or one quarter and two dimes.

#include <threads.h>
#include <stdio.h>

typedef struct currency_s {
  int quarters;
  int dimes;
  int nickels;
  int pennies;
  mtx_t lock;
} currency_t;
 
currency_t *set_quarters(int quantity, currency_t *currency) {
  if (thrd_success != mtx_lock(&currency->lock)) {
    /* Handle error */
  }
  currency->quarters += quantity;
  if (thrd_success != mtx_unlock(&currency->lock)) {
    /* Handle error */
  }
  return currency;
}
currency_t *set_dimes(int quantity, currency_t *currency) {
  if (thrd_success != mtx_lock(&currency->lock)) {
    /* Handle error */
  }
  currency->dimes += quantity;
  if (thrd_success != mtx_unlock(&currency->lock)) {
    /* Handle error */
  }
  return currency;
}
currency_t *set_nickels(int quantity, currency_t *currency) {
  if (thrd_success != mtx_lock(&currency->lock)) {
    /* Handle error */
  }
  currency->nickels += quantity;
  if (thrd_success != mtx_unlock(&currency->lock)) {
    /* Handle error */
  }
  return currency;
}
currency_t *set_pennies(int quantity, currency_t *currency) {
  if (thrd_success != mtx_lock(&currency->lock)) {
    /* Handle error */
  }
  currency->pennies += quantity;
  if (thrd_success != mtx_unlock(&currency->lock)) {
    /* Handle error */
  }
  return currency;
}
 
int init_45_cents(void *currency) {
  currency_t *c = set_quarters(1, set_dimes(2, currency));
  /* Validate values are correct */
  return 0;
}
int init_60_cents(void* currency) {
  currency_t *c = set_quarters(2, set_dimes(1, currency));
  /* Validate values are correct */
  return 0;
}
 
int main(void) {
  int result;
  thrd_t thrd1;
  thrd_t thrd2;
  currency_t currency = {0, 0, 0, 0};
 
  if (thrd_success != mtx_init(&currency.lock, mtx_plain)) {
    /* Handle error */
  }
  if (thrd_success != thrd_create(&thrd1, init_45_cents, &currency)) {
    /* Handle error */
  }
  if (thrd_success != thrd_create(&thrd2, init_60_cents, &currency)) {
    /* Handle error */
  }
  
  if (thrd_success != thrd_join(thrd1, NULL)) {
    /* Handle error */
  }
  if (thrd_success != thrd_join(thrd2, NULL)) {
    /* Handle error */
  }
 
  printf("%d quarters, %d dimes, %d nickels, %d pennies\n",
         currency.quarters, currency.dimes, currency.nickels, currency.pennies);
 
  mtx_destroy( &currency.lock);
  return 0;
}

#include <threads.h>
#include <stdio.h>
typedef struct currency_s {
  int quarters;
  int dimes;
  int nickels;
  int pennies;
  mtx_t lock;
} currency_t;
 
currency_t *set_quarters(int quantity, currency_t *currency) {
  currency->quarters += quantity;
  return currency;
}
currency_t *set_dimes(int quantity, currency_t *currency) {
  currency->dimes += quantity;
  return currency;
}
currency_t *set_nickels(int quantity, currency_t *currency) {
  currency->nickels += quantity;
  return currency;
} 
currency_t *set_pennies(int quantity, currency_t *currency) {
  currency->pennies += quantity;
  return currency;
}
 
int init_45_cents(void *currency) {
  currency_t *c = (currency_t *)currency;
  if (thrd_success != mtx_lock(&c->lock)) {
    /* Handle error */
  }
  set_quarters(1, set_dimes(2, currency));
  if (thrd_success != mtx_unlock(&c->lock)) {
    /* Handle error */
  }
  return 0;
}
int init_60_cents(void *currency) {
  currency_t *c = (currency_t *)currency;
  if (thrd_success != mtx_lock(&c->lock)) {
    /* Handle error */
  }
  set_quarters(2, set_dimes(1, currency));
  if (thrd_success != mtx_unlock(&c->lock)) {
    /* Handle error */
  }
  return 0;
}
 
int main(void) {
  int result;
  thrd_t thrd1;
  thrd_t thrd2;
  currency_t currency = {0, 0, 0, 0};
 
  if (thrd_success != mtx_init(&currency.lock, mtx_plain)) {
    /* Handle error */
  }
  if (thrd_success != thrd_create(&thrd1, init_45_cents, &currency)) {
    /* Handle error */
  }
  if (thrd_success != thrd_create(&thrd2, init_60_cents, &currency)) {
    /* Handle error */
  }
 
  if (thrd_success != thrd_join(thrd1, NULL)) {
    /* Handle error */
  }
  if (thrd_success != thrd_join(thrd2, NULL)) {
    /* Handle error */
  }
 
  printf("%d quarters, %d dimes, %d nickels, %d pennies\n",
         currency.quarters, currency.dimes, currency.nickels, currency.pennies);
 
  mtx_destroy(&currency.lock);
  return 0;
}

Bibliography

Image Removed

Image Removed

Image Removed