scitools.com

← Graph catalog

Shared Tasks - Lock Order is one of the interactive graphs Understand can draw of your code — call trees, dependencies, control flow, and more.

Shared Tasks - Lock Order

Languages: Any
Targets: Architectures
Find possible deadlocks between tasks that take the same locks in different orders.

Each node is a lock. An edge from one lock to another means a task takes the second lock while it may still hold the first. The edge is labeled with the task. Locks and edges that form a possible deadlock are red.

Dashed red edges are the suggested fix for their deadlock: change those tasks to take the two locks in the opposite order, matching the other tasks. It is the order used at the fewest call sites.

A cycle is a possible deadlock when its edges come from different tasks. If those tasks always hold another common lock at the same time, that lock serializes them and the cycle is not reported.

Architecture Structure

The architecture lists the tasks and the lock and unlock functions. Each lock and unlock pair goes in its own group:

Locks are told apart by the object whose address is passed to the lock function, like pthread_mutex_lock(&mutex). A lock reached through a pointer, a parameter, an array element or a struct member, or on a line that also takes the address of another object, can't be identified, so it is left out. List only lock functions that wait: pthread_mutex_trylock returns instead, so it can't deadlock.

Calls carry held locks into a function. A function passed by address, like a callback, runs later, so it is checked with no locks held. List each function started as a thread, like one passed to pthread_create, as its own task.

A large number of locks taken in many orders can make the search for deadlocks slow. If it stops early, the graph says so.

See also the shared tasks graph by function. Also related are concurrency plugins.

This variant is a plugin. It can be enabled/disabled from the Plugin Manager.