CERT
Skip to end of metadata
Go to start of metadata

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 CON07-C. Ensure that compound operations on shared variables are atomic for more information.

Noncompliant Code Example

This noncompliant code example 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.

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.

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.

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.

Noncompliant Code Example

This code remains unsafe even if it uses a mutex on the set functions to guard modification of the currency:

Compliant Solution

This compliant solution uses a mutex, but instead of guarding the set functions, it guards the init functions, which are invoked at thread creation.

Consequently this compliant solution is thread-safe, and will always print out the same number of quarters as dimes.
 

Risk Assessment

Failure to ensure the atomicity of two or more operations that must be performed as a single atomic operation can result in race conditions in multithreaded applications.

 

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

CON08-C

Low

Probable

Medium

P4

L3

 

Related Guidelines

 
CERT Oracle Secure Coding Standard for JavaVNA03-J. Do not assume that a group of calls to independently atomic methods is atomic
VNA04-J. Ensure that calls to chained methods are atomic

MITRE CWE

CWE-362, Concurrent execution using shared resource with improper synchronization ("race condition")
CWE-366, Race condition within a thread
CWE-662, Improper synchronization

 

Bibliography

[ISO/IEC 9899:2011]

Subclause 7.26, "Threads <threads.h>"


  

 

2 Comments

  1. The first Compliant Solution relies on the mutex being recursive, but this is not mentioned anywhere.