New release of deadlock detection tools - 1.3.0.406

| 0 Comments
We've released new versions of both our Lock Inversion Detector, LID and our Lock Inversion Analyser, LIA today.

This release fixes a problem when running LIA against an executable which has been compiled with Frame Pointer Omission enabled. This causes some call stacks to be reported as zero length and we were failing to treat these correctly which led to a vast number of duplicate lock sequences being created. Also a bug has been fixed in LIA which caused it to fail to use symbol paths supplied on the command line when looking up symbols.

We've also added several new command line switches to LIA to enable you to ignore inversions that occur in specific dlls, limit the number of lock inversions reported, ignore stack frames which are shorter than a configurable length and force slower but more reliable call stack collection to be used.

All customers are being contacted via email with details of how to obtain the latest release of LIA and you can download the latest version of LID from here (if you've already registered for the updates mailing list then simply reply to the email notification and we'll send you the latest version).

Do continue to get in touch with comments and suggestions and any problems that you have.
We've released new versions of both our Lock Inversion Detector, LID and our Lock Inversion Analyser, LIA today.

This release is a simple bug fix release which fixes a problem where we could incorrectly treat two critical sections or SRW locks which happened to be created at the same memory address as the same lock for inversion tracking purposes. This could happen if a lock is created in dynamic memory, used and then cleaned up and then the memory is reused in such a way that a new lock is created with the same memory address for its CRITICAL_SECTION or SRWLOCK data. In such cases we would treat the two locks as the same lock when looking for lock inversions and this could cause us to report spurious inversions in some situations.

All customers are being contacted via email with details of how to obtain the latest release of LIA and you can download the latest version of LID from here (if you've already registered for the updates mailing list then simply reply to the email notification and we'll send you the latest version).

Do continue to get in touch with comments and suggestions and any problems that you have.
We've released new versions of both our Lock Inversion Detector, LID and our Lock Inversion Analyser, LIA today.

This release is a simple bug fix release which fixes issues around the DuplicateHandle() API which is tracked as part of our support for tracking lock inversions which include Mutexes.

All customers are being contacted via email with details of how to obtain the latest release of LIA and you can download the latest version of LID from here (if you've already registered for the updates mailing list then simply reply to the email notification and we'll send you the latest version).

Do continue to get in touch with comments and suggestions and any problems that you have.

New release of deadlock detection tools - 1.2.0.307

| 0 Comments
We've released new versions of both our Lock Inversion Detector, LID and our Lock Inversion Analyser, LIA today.

This release adds the instrumentation of more locking APIs to the tools. We now track Slim Reader Writer (SRW) locks and Mutexes as well as still tracking Critical Sections. These changes make the tools more useful for more people; we tended to focus on using mainly Critical Sections in our code which is why these other lock types have taken longer to be added to the tools. We've extended the API support for Critical Sections to include SleepConditionVariableCS() which operates as a LeaveCriticalSection() when the function is called followed by an EnterCriticalSection() before it returns. If you want to exclude certain lock types from the instrumentation then there are command line switches to do so, -noCS, -noSRW and -noMUT.

In addition, in the Lock Inversion Analyser, you can now specify Critical Sections that you wish to ignore by first obtaining their lock id by running with -lockID and the running again with -excludeLock; see the command line help for more information. You can also only track Critical Sections for which the analyser sees the call to CreateCriticalSection(), or equivalent, by using the command line switch -seeCreate; this can reduce the number of locks that you instrument in some situations.

Slim Reader Writer locks cannot be acquired recursively and attempting to do so will cause a deadlock. Both LID and LIA will detect this deadlock, terminate the target process and pinpoint the problem location.

All customers are being contacted via email with details of how to obtain the latest release of LIA and you can download the latest version of LID from here (if you've already registered for the updates mailing list then simply reply to the email notification and we'll send you the latest version).

Do continue to get in touch with comments and suggestions and any problems that you have.

New release of deadlock detection tools

| 0 Comments
We've released new versions of both LID and LIA today. These releases include many changes that we've been testing with customers over the last couple of months and mainly deal with fixing hangs during the shutdown of managed applications when they are run under the tools and performance improvements when running on target processes which use a large number of locks and create a large number of lock acquisition sequences.

In addition we've fixed some bugs with TryEnterCriticalSection() where we were incorrectly reporting lock inversions when a call to TryEnterCriticalSection() returned FALSE and added a few extra command line switches so that you can show progress during lock inversion detection after the target process completes.

You can download the latest version of LID from here and all customers are being contacted via email with details of how to download the latest release of LIA.

Do continue to get in touch with comments and suggestions and any problems that you have.
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.
TwoThreadsDeadlocked.png

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.

Where do deadlocks come from?

| 0 Comments
Deadlocks are one of the most annoying problems that can occur in multi-threaded programming with parts of a program simply stopping work and waiting indefinitely.

At their simplest, deadlocks are caused when one thread of execution, "Thread A", obtains and holds a lock which another thread of execution, "Thread B", requires whilst itself being blocked from obtaining a lock that it requires because "Thread B" already holds it..
TwoThreadsDeadlocked.png

Logo competion underway at 99designs.com

| 0 Comments
I've run two logo competitions at 99designs.com, this one for The Server Framework and this one for JetByte Limited.

Both were a success and resulted in logos that I'm very happy with, so here we go again!

Updated 23 June 2011 - as you can see, we've now got a logo!