MISRA C:2012 Rule 22.17
No thread shall unlock a mutex or call cnd_wait()
or
cnd_timedwait()
for a mutex it has not locked before
Since R2024b
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
No thread shall unlock a mutex or call cnd_wait()
or
cnd_timedwait()
for a mutex it has not locked
before.
This rule comes from MISRA C™: 2012 Amendment 4.
Rationale
If a thread attempts to unlock a mutex that it did not lock previously, the resulting behavior is undefined. Consider this code:
mtx_t mutex; void foo() { //... mtx_unlock(&mutex); }
foo()
does not lock
mutex
but attempts to unlock it, resulting in undefined
behavior.If a thread attempts to call the functions cnd_wait()
or
cnd_timedwait()
using a mutex without locking the mutex first, the
resulting behavior is undefined. Consider this code:
mtx_t mutex; cnd_t cnd1 void foo() { //... cnd_wait(&mutex, &cnd1); }
foo
does not lock
mutex
but calls cnd_wait()
using the mutex
object, resulting in undefined behavior.To avoid undefined behavior, a thread must lock a mutex before attempting either of these operations:
Unlocking the mutex
Calling
cnd_wait()
orcnd_timedwait()
using the mutex
Polyspace Implementation
Polyspace reports a violation of this rule if either of these conditions is true:
A thread unlocks a mutex object before locking it.
A thread attempts to unlock a previously locked mutex twice without a locking operation between the unlocking operations.
Troubleshooting
If you expect a rule violation but do not see it, refer to Diagnose Why Coding Standard Violations Do Not Appear as Expected.
Examples
Check Information
Group: Resources |
Category: Required |
AGC Category: Required |
Version History
Introduced in R2024b