Main Content

CERT C++: CON56-CPP

Do not speculatively lock a non-recursive mutex that is already owned by the calling thread

Since R2023b

Description

Rule Definition

Do not speculatively lock a non-recursive mutex that is already owned by the calling thread.1

Polyspace Implementation

The rule checker checks for the issue Attempt to lock mutex that is already owned by calling thread.

Examples

expand all

Issue

This issue occurs when a thread invokes std::try_lock(), std::try_lock_for() or std::try_lock_until() on a non-recursive mutex that is already locked by this thread. Non-recursive mutexes include variables of type std::mutex, std::timed_mutex, etc.

Risk

Functions such as std::try_lock() attempt to lock a mutex. If the mutex is already locked by another thread, the function returns a boolean value indicating that the mutex could not be locked.

If the thread that attempts to lock a non-recursive mutex has already locked the mutex previously, the behavior is undefined (C++14 Standard).

Fix

Change the placement of locks to avoid trying to lock a mutex that is already locked by the current thread. Alternatively, if you want to lock the same mutex multiple times in the current thread, use recursive mutexes, that is, variables of type std::recursive_mutex and std::recursive_timed_mutex.

Example — Attempt to Lock Already Locked Mutex

In this example, the thread t begins with the function begin_task(). This function creates an std::lock_guard object lock to lock the mutex shared_var_mutex. The function then calls another function increment_shared_var(), which attempts to lock shared_var_mutex once again using std::try_lock().

#include <mutex>
#include <thread>

int shared_var = 0;
std::mutex shared_var_mutex;

void do_thread_safe_work();

void increment_shared_var()
{
    while (!shared_var_mutex.try_lock()) //Noncompliant
        {

        }
    shared_var++;
    shared_var_mutex.unlock();
}

void begin_task()
{
    std::lock_guard<std::mutex> lock(shared_var_mutex);
    increment_shared_var();
}

void main()
{
    std::thread t(begin_task);
    increment_shared_var();
    t.join();
}
Correction — Place Locks as Close as Possible to Operations on Shared Variables

To fix the double lock issue, lock a mutex only when needed. In this example, instead of locking shared_var_mutex speculatively in the function begin_task(), lock this mutex only before performing operations on the shared variable shared_var.

#include <mutex>
#include <thread>

int shared_var = 0;
std::mutex shared_var_mutex;

void do_thread_safe_work();

void increment_shared_var()
{
    while (!shared_var_mutex.try_lock()) //Compliant
        {

        }
    shared_var++;
    shared_var_mutex.unlock();
}

void begin_task()
{
     increment_shared_var();
}

void main()
{
    std::thread t(begin_task);
    increment_shared_var();
    t.join();
}

Check Information

Group: Rule 10. Concurrency (CON)

Version History

Introduced in R2023b


1 This software has been created by MathWorks incorporating portions of: the “SEI CERT-C Website,” © 2017 Carnegie Mellon University, the SEI CERT-C++ Web site © 2017 Carnegie Mellon University, ”SEI CERT C Coding Standard – Rules for Developing safe, Reliable and Secure systems – 2016 Edition,” © 2016 Carnegie Mellon University, and “SEI CERT C++ Coding Standard – Rules for Developing safe, Reliable and Secure systems in C++ – 2016 Edition” © 2016 Carnegie Mellon University, with special permission from its Software Engineering Institute.

ANY MATERIAL OF CARNEGIE MELLON UNIVERSITY AND/OR ITS SOFTWARE ENGINEERING INSTITUTE CONTAINED HEREIN IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This software and associated documentation has not been reviewed nor is it endorsed by Carnegie Mellon University or its Software Engineering Institute.