parts/6.63.ProtocolLockErrors-CGM.md

6.63 Protocol Lock Errors [CGM]

6.63.1 Applicability to language

The vulnerability as described in ISO/IEC 24772-1 clause 6.63 is applicable to C++.

This subclause requires a complete rewrite to have it reflect C++ issues.

Difference between threads and tasks. Can threads and tasks coexist?

Deadlock with single mutex,

The C standard does not provide hidden protocols. Although the vulnerability does not apply to the C language, there could exist an application vulnerability if a program uses synchronization mechanisms incorrectly. For example:

atomic int a;

int b;

/* . . . */

a += b; // This operation is an atomic read-modify-write of the variable ‘a’.

a = a + b; // This statement contains two accesses to ‘a’ and is not atomic.

6.63.2 Avoidance mechanisms for language users

To avoid the vulnerability or mitigate its ill effects, C++ software developers can:

• Use the avoidance mechanisms of ISO/IEC 24772-1 clause 6.63.5.

• Be aware of the operation of each synchronization mechanism, such as the cases where accesses to atomic variables may occur more than once in a statement.

• Use higher level building blocks (such as TBB) in preference to …

• Use the C++ Task mechanism in preference to threads …

• Always put the acquisition and release of mutexes and the data access in a wrapper function. (i.e. Do not call member functions of std::mutex, std::timed_mutex, std::recursive_mutex, std::recursive_timed_mutex, std::shared_mutex and std::shared_timed_mutex objects directly.)

• Use std::lock(), std::try_lock() or std::scoped_lock to acquire multiple mutexes in same scope. (std::lock() permits multiple mutexes at the same time).

• Use std::lock() only where multiple locks must be locked together and use std::lock_guard with the std::adopt_lock argument for all mutexes (needs example) see std::lock() example on cppreference.com.

• Wrap mutex locks std::lock or std::try_lock with std::lock_guard, std::unique_lock or std::shared_lock with adopt_lock tag within the same scope

• If explicit locking are used, ensure that the lock is released on every exit path, including exceptions. Use lock_guard, scope_lock and unique_lock in preference to lock(), unlock(), and try_lock(),

• Do not use platform specific multi-threading facilities

• A thread shall not access objects whose lifetime has expired

• 0.4.4 [12] Do not destroy objects of the following types std::mutex, std::timed_mutex, std::recursive_mutex, std::recursive_timed_mutex, std::shared_mutex, std::shared_timed_mutex if object is in locked or shared locked state Do not destroy a mutex while it is locked

• 0.4.5 [13] Mutexes locked with std::lock or std::try_lock shall be wrapped with std::lock_guard, std::unique_lock or std::shared_lock with adopt_lock tag within the same scope Ensure actively held locks are released on exceptional conditions 12

• 0.4.6 [14] Do not call virtual functions and callable objects passed by argument of the function within the scope of locked mutex Never call unknown code while holding a lock (e.g., a callback) 12

• 0.4.7 [15] Avoid deadlock by locking in a predefined order

• 0.4.8 [16] Objects of std::lock_guards, std::unique_locks, std::shared_lock and std::scoped_lock classes shall always be named Remember to name your lock_guards and unique_locks

• 0.4.9 [17] Define a mutex together with the data it guards. Use synchronized_value<T> where possible 13

• 0.4.10 [18] Do not speculatively lock a non-recursive mutex that is already owned by the calling thread 14

• 0.4.11 [19] There shall be no code path which results in locking of the non-recursive mutex within the scope when this mutex is already locked Within the scope of a lock, ensure that no static path results in a lock of the same mutex 14

• 0.4.12 [20] The order of nested locks unlock shall form a DAG Ensure that order of nesting of locks in a project forms a DAG 15

• 0.4.13 [21] std::recursive_mutex and std::recursive_timed_mutex should not be used Do not use std::recursive_mutex 17

• 0.4.14 [22] There should be a code path, where at least one member functions is called for std::unique_lock objects Only use std::unique_lock when std::lock_guard cannot be used 18

• 0.5 Conditional variable 19

• 0.5.1 [23] std::condition_variable::wait, std::condition_variable::wait_for, std::condition_variable::wait_until shall always be called with a condition predicate 19

• 0.5.2 [24] Wrap functions that can spuriously wake up in a loop 20

• 0.5.3 [25] std::conditional_variable::notify_one() can be used if all threads must perform the same set of operations after waking up Preserve thread safety and liveness when using condition variables 21

• 0.5.4 [26] Do not use std::condition_variable_any on a std::mutex

• [0.10.1 [35] Source CCG Rule CP.100: Don't use lock-free programming unless you absolutely have to

  27](https://docs.google.com/document/d/14E0BYqsH_d7fMKvXvaZWoNWtIC65cYBw0aZp4dlev0Q/edit#heading=h.3hq5f8vdw7d)

• 0.10.2 [36] Source CCG Rule CP.101: Distrust your hardware/compiler combination

• 0.10.3 [37] Source CCG Rule CP.102: Carefully study the literature

• 0.10.4 [38] Source CCG Rule CP.110: Do not write your own double-checked locking for initialization

• 0.10.5 [39] Source HIC Rule 18.2.4 Use std::call_once to ensure a function is called exactly once (rather than the Double-Checked Locking pattern)

• 0.10.6 [40] Source CCG Rule CP.111: Use a conventional pattern if you really need double-checked locking