Tutorial Archives

In the previous tutorials I showed how LID and LIA, our deadlock detection tools, could be used to pinpoint lock inversions, show you deadlocks which are lurking in your code and save you hours of debugging time. The examples used so far are very simple and all of the locks are acquired on the same thread. The tools recognise that although these are lock inversions they're benign as only one thread ever acquires the locks in each sequence and a single thread cannot deadlock itself (unless it's using locks which are not re-entrant!).

To help reduce potential clutter from the output you can suppress single threaded lock inversions using the -skipSingleThread command line switch.

Personally I prefer to remove ALL lock order inversions but if you want to ignore single threaded inversions then you can.
In the previous tutorial I showed how LID and LIA, our deadlock detection tools, could be used to pinpoint lock inversions and show you deadlocks which are lurking in your code. The examples used were very simple, with only the two locks involved in each lock acquisition sequence. Real code is seldom so clean.

Real world code's use of locks can be surprisingly complex; object oriented encapsulation hides the use of locks inside of objects and layered designs may use locks in the layers that call into your code and may use locks in the layers that you call into. Deadlocks caused by lock inversions involve two locks but there may be many more locks being used by the code that causes the lock inversion. Our tools build graphs of the locks that are taken by your code and then search those graphs for lock inversions. Once problems are found we reduce the graphs to just the locks that cause the problem, stripping away complexity and exposing the details that let you remove the potential deadlock from your code. An example probably helps...
As I mentioned before, deadlocks occur because of lock inversions, that is one thread is holding lock 1 and requires lock 2 and another thread is holding lock 2 and requires lock1.

Our tools help you find lock inversions in your code without requiring deadlocks to occur, all you need to do is run the code under our Lock Inversion Detector, LID, or our Lock Inversion Analyser, LIA.

About this Archive

This page is an archive of recent entries in the Tutorial category.

General is the previous category.

Releases is the next category.

This is where we write about the development of Lock Explorer, a suite of tools for locating lock inversions, finding deadlocks before they happen and investigating lock usage, contention and performance in multi-threaded code.

Find recent content on the main index or look in the archives to find all content.