While working on the logging mechanism in the RunAsSys example of the JEDI, I encountered a really strange problem on XP systems. The application worked fine on Vista system. However on Windows XP, it just stopped working with no response at all. This wasn’t the usual dead lock situation you know in multi threaded application, because there were only one thread. So what happened? I could luckily debug the program and found out that it hang on a log sequence. Going deeper, I found out that on XP a call to EnterCriticalSection hang indefinitely when it was called right after two subsequent calls to LeaveCriticalSection. Of course it was wrong. I should always leave the critical section only once for every entering. How could that happen? Just accident. I didn’t realize that the Delphi function “exit” called within try/finally, jumps into the finally block first and then exits the function.

  1. procedure XY;
  2. var CS : TCriticalSection;
  3. try
  4.   CS.Enter;
  5.   if SomeThingBadHappensHere then
  6.   begin
  7.     CS.Leave;
  8.     exit;
  9.   end;
  10. finally
  11.   CS.Leave;
  12. end;

Thus the next call to Enter will hang on XP Systems. It is in contrast to Vista where it works. So why did this happen? Maybe the internal lock may tell us more. The following output comes from this little test application:

  1. begin
  2.   CS := TCriticalSectionDeb.Create;
  3.   DebugOut;
  4.   CS.Enter;
  5.   DebugOut;
  6.   CS.Enter;
  7.   DebugOut;
  8.   CS.Enter;
  9.   DebugOut;
  10.  
  11.   DebugOut(‘leave’);
  12.   CS.Leave;
  13.   DebugOut;
  14.  
  15.   CS.Leave;
  16.   DebugOut;
  17.   readln;
  18. end;

The result shows the following output. The values in the left column are from Windows XP, where the ones on the right side come from Windows Vista.

Version XP Vista
LockCount: -1 -1
RecursionCount: 0 0
LockCount: 0 -2
RecursionCount: 1 1
LockCount: 1 -2
RecursionCount: 2 2
LockCount: 2 -2
RecursionCount: 3 3
leave
LockCount: 2 -2
RecursionCount: 3 3
LockCount: 1 -2
RecursionCount: 2 2
LockCount: 0 -2
RecursionCount: 1 1
LockCount: -1 -1
RecursionCount: 0 0

You see a significant difference between XP and Vista. Windows XP counts the (internal) Lockcount upwards. It is in contrast to Windows Vista, where the LockCount counts downwards and stops at -2. But why does a call to EnterCriticalSection lock up the app in XP and not in Vista?

The initial state at the beginning and at the (proper) end is

LockCount: -1 -1
RecursionCount: 0 0

In this case, we can safely call EnterCriticalSection without waiting. There is no lock on the section. Let us see and compare what happens when we call Leave one more time.

LockCount: -2 -1
RecursionCount: -1 -1

Windows XP decreases the RecursionCount and additionally the LockCount value. In Vista only the RecursionCount is decreased. That is the difference because EnterCriticalSection blocks only if it finds a LockCount different of -1 (the initial state). The Windows Vista API seems to be aware that the same thread calls EnterCriticalSection several times and thus just increases the recursion value.

That is the reason why we have to be careful even if we use critical sections in only one thread. The MSDN help about LeaveCriticalSection states this problem the following way:

If a thread calls LeaveCriticalSection when it does not have ownership of the specified critical section object, an error occurs that may cause another thread using EnterCriticalSection to wait indefinitely.

It should be instead of “another thread” say “any thread”.

How did I get the lock count information from the VCL TCriticalSection? The next code shows this simple task:

  1. type
  2.   TCriticalSectionDeb = class(TCriticalSection)
  3.   public
  4.     property Section: TRTLCriticalSection read FSection;
  5.   end;
  6.  
  7. var CS : TCriticalSectionDeb;
  8.  
  9. procedure DebugOut(Head : String = ”);
  10. begin
  11.   Writeln;
  12.   if Length(Head) > 0 then
  13.     WRiteln(Head);
  14.   Writeln(‘LockCount: ‘, CS.Section.LockCount);
  15.   Writeln(‘RecursionCount: ‘, CS.Section.RecursionCount);
  16.   Writeln(‘EntryCount: ‘, CS.Section.DebugInfo.EntryCount);
  17. end;
  18.  
  19. begin
  20.   CS := TCriticalSectionDeb.Create;
  21.  
  22.   DebugOut;
  23.   CS.Enter;
  24.   DebugOut;
  25.   …
Send post as PDF to www.pdf24.org
convert this post to pdf.