CERT C++: CON51-CPP

Ensure actively held locks are released on exceptional conditions

Since R2023b

Description

This checker is deactivated in a default Polyspace^® as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

Rule Definition

Ensure actively held locks are released on exceptional conditions.¹

Polyspace Implementation

The rule checker checks for Lock possibly not released on exception.

Examples

Lock possibly not released on exception

Issue

This issue occurs when the following happens in sequence:

• You explicitly lock an std::mutex variable using the lock() member function.

• You later unlock the std::mutex variable using the unlock() member function but if a prior step throws an exception, the unlocking is bypassed.

  The issue also occurs if you fail to call the unlock() function altogether.

The checker for this issue considers any undefined function without a noexcept clause or with a noexcept(false) clause as possibly throwing an exception. If a function has a definition, it is considered to throw an exception if:

• It throws an exception explicitly.

• It calls another function that throws an exception.

The event list in the traceback for this checker shows one possible function that might throw an exception and prevent the release of the locked std::mutex variable.

Risk

An std::mutex variable when locked in a thread prevents other threads from accessing shared data. If the variable is not unlocked, other threads might wait for the shared data indefinitely.

Fix

To avoid locks not being released on exceptions, do one of the following:

• Add unlock steps in catch clauses that catch any exceptions thrown.

• Instead of a naked std::mutex variable that needs to be locked and unlocked explicitly, create an std::lock_guard, std::unique_lock or std::shared_lock object from the variable.

  For variables of these class types, if an exception occurs, the class destructor is invoked to automatically unlock the mutex.

Example — Possible Exception in Function Call Might Prevent Unlock

In this example, the std::mutex variable is locked using the lock() member function and unlocked using the unlock() member function. However, the function manipulate_data() might throw an exception and the execution might not reach the call to the unlock() function.

#include <mutex>

void manipulate_data();

void handle_shared_data(std::mutex &data_mtx)
{
    data_mtx.lock();
    manipulate_data();
    data_mtx.unlock(); //Noncompliant
}

Correction — Add Unlocks in catch Clauses for Exception

One possible solution is to catch all exceptions thrown and add calls to unlock() functions in the catch clauses.

#include <mutex>

void manipulate_data();

void handle_shared_data(std::mutex &data_mtx)
{
    data_mtx.lock();
    try
        {
            manipulate_data();
        }
    catch (...)
        {
            data_mtx.unlock(); //Compliant
            return;
        }
    data_mtx.unlock();
}

Correction — Use std::lock_guard Variable

Another possible solution is to create an std::lock_guard variable from the std::mutex variable and use the latter for protection of shared data.

#include <mutex>

void manipulate_data(); 

void handle_shared_data(std::mutex &data_mtx)
{
    std::lock_guard<std::mutex> guard(data_mtx); //Compliant
    manipulate_data();
}

Check Information

Group: Rule 10. Concurrency (CON)

Version History

Introduced in R2023b