Destruction of locked mutex
Task tries to destroy a mutex in the locked state
Description
This checker is deactivated in a default Polyspace® as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).
This defect occurs when a task destroys a mutex after it is locked (and before it is unlocked). The locking and destruction can happen in the same task or different tasks.
Risk
A mutex is locked to protect shared variables from concurrent access. If a mutex is destroyed in the locked state, the protection does not apply.
Fix
To fix this defect, destroy the mutex only after you unlock it. It is a good design practice to:
Initialize a mutex before creating the threads where you use the mutex.
Destroy a mutex after joining the threads that you created.
On the Result Details pane, you see two events, the locking and destruction of the mutex, and the tasks that initiated the events. To navigate to the corresponding line in your source code, click the event.
Examples
Result Information
Group: Concurrency |
Language: C | C++ |
Default: Off |
Command-Line Syntax: DESTROY_LOCKED |
Impact: Medium |
Version History
Introduced in R2016b
See Also
Tasks (-entry-points)
| Configure multitasking manually
| Target processor type (-target)
| Find defects (-checkers)
| Data race
| Data race through standard library function call
| Deadlock
| Double lock
| Double unlock
| Missing lock
| Missing unlock
Topics
- Analyze Multitasking Programs in Polyspace
- Interpret Bug Finder Results in Polyspace Desktop User Interface
- Interpret Bug Finder Results in Polyspace Access Web Interface (Polyspace Access)
- Address Results in Polyspace User Interface Through Bug Fixes or Justifications
- Address Results in Polyspace Access Through Bug Fixes or Justifications (Polyspace Access)