Analysis of Lock Usage

LockLint's primary role is to report on lock usage inconsistencies that may lead to data races and deadlocks. The analysis of lock usage occurs when you use the analyze subcommand. The result is a report on the following problems:

• Functions that produce side effects on locks or violate assertions made about side effects on locks (for example, a function that changes the state of a mutex lock from locked to unlocked). The most common unintentional side effect occurs when a function acquires a lock on entry, and then fails to release it at some return point. That path through the function is said to acquire the lock as a side effect. This type of problem may lead to both data races and deadlocks.

• Functions that have inconsistent side effects on locks (that is, different paths through the function) yield different side effects. This may be a limitation of LockLint (see "Limitations of LockLint") and a common cause of errors. LockLint cannot handle such functions. It always reports them as errors and does not correctly interpret them. For example, one of the returns from a function may forget to unlock a lock acquired in the function.

• Violations of assertions about which locks should be held upon entry to a function. This problem may lead to a data race.

• Violations of assertions that a lock should be held when a variable is accessed. This problem may lead to a data race.

• Violations of assertions that specify the order in which locks are to be acquired. This problem may lead to a deadlock.

• Failure to use the same, or asserted, mutex lock for all waits on a particular condition variable.

• Miscellaneous problems related to analysis of the source code in relation to assertions and locks.

Post-analysis Queries

After analysis, you can use LockLint subcommands for:

• Finding additional locking inconsistencies.

• Forming appropriate declare, assert, and ignore subcommands. These can be specified after you've restored LockLint's state, prior to rerunning the analysis.

One such subcommand is order, which you can use to make inquiries about the order in which locks have been acquired. This information is particularly useful in understanding lock ordering problems and making assertions about those orders so that LockLint can more accurately diagnose potential deadlocks.

Another such subcommand is vars. The vars subcommand reports which locks are consistently held when a variable is read or written (if any). This information can be useful in determining the protection conventions in code where the original conventions were never documented, or the documentation has become outdated.