Wer mich kennt, weiß daß ich sehr schnell ballistisch werde, wenn ich irgendwo Code sehe, der nichtriviale globale Objekte enthält, oder Code einer DLL, deren DllMain ganz dumme Sachen macht. Anhand eines Beispiels möchte ich hier jetzt einmal ein Phänomen vorstellen, das als "Loader Lock" bekannt ist.

Das Beispiel besteht aus einer ganz trivialen Exe-Datei ("Loader") und einer DLL ("Locker"). Mit Hilfe von Aufrufen des APIs Sleep provoziere ich eine Race Condition, wie sie im wirklichen Leben auch auftreten kann. Und damit niemand glaubt, daß das ein konstruiertes Beispiel sei: Es ist mir im richtigen Leben erst kürzlich begegnet. Das komplette Projekt (VC6) kann man sich hier downloaden

Erstmal hier der Code in der DLL:

#include "stdafx.h"
#include <tchar.h>

#define USE_GLOBAL_OBJECT 1


static void CreateAndWaitEvent()
{
  HANDLE hEvent = CreateEvent(NULL, FALSE, FALSE, 
    _T("oohdelalllyeh!"));
  if(hEvent)
  {
    WaitForSingleObject(hEvent, INFINITE);
    CloseHandle(hEvent);
  }
}

#if USE_GLOBAL_OBJECT
class CDoomed
{

  public:
    CDoomed()
    {
      CreateAndWaitEvent();
    }
};

CDoomed g_Doomed;

#endif 


BOOL APIENTRY DllMain( HANDLE /*hModule*/, 
                       DWORD  ul_reason_for_call, 
                       LPVOID /*lpReserved*/ )
{
#if !USE_GLOBAL_OBJECT
  if (DLL_PROCESS_ATTACH==ul_reason_for_call)
    CreateAndWaitEvent();    
#endif
  ul_reason_for_call;
  return TRUE;
}

Was passiert hier? Mit Hilfe des Makros USE_GLOBAL_OBJECT wird entschieden, ob entweder ein globales Objekt der Klasse CDoomed instanziiert wird (USE_GLOBAL_OBJECT=1), oder die Funktion CreateAndWaitEvent() (USE_GLOBAL_OBJECT=0) beim Process Attach der DLL aus DllMain heraus aufgerufen aufgerufen wird. Im ersteren Fall wird auch die Funktion CreateAndWaitEvent() aufgerufen, jedoch aus dem Konstruktor der Klasse CDoomed, von der die globale Instanz g_Doomed existiert.
Die Funktion CreateAndWaitEvent() erzeugt oder öffnet ein bereits existierendes Named Event Kernel Object mit dem Namen "oohdelalllyeh!". Auf dessen Signalisierung wartet diese Funktion und kehrt dann zum Aufrufer zurück. So weit so gut, ist ja schließlich keine wahrhafte Raketenwissenschaft.

Jetzt zu der Exe-Datei, ihr Code schaut folgendermaßen aus:

#include "stdafx.h"
#include <process.h>
#include <stdio.h>
#include <tchar.h>
#include <windows.h>

#ifndef dimof
#define dimof(a) (sizeof(a)/sizeof(a[0]))
#endif // dimof


unsigned __stdcall ThreadFunction(LPVOID)
{
  Sleep(5000);
  HMODULE hModule = LoadLibrary(_T("locker"));
  if (hModule)
    FreeLibrary(hModule);
  return TRUE;  
}

int main(int /*argc*/, char* /*argv*/[])
{
  unsigned tid;
  TCHAR szFileName[_MAX_PATH];

  HANDLE hEvent = CreateEvent(NULL, FALSE, FALSE, 
    _T("oohdelalllyeh!"));


  HANDLE hThread = (HANDLE)_beginthreadex(NULL, 0L, 
    ThreadFunction, NULL, 0L, &tid);

  Sleep(2000);
  
  GetModuleFileName(NULL, szFileName, dimof(szFileName));

  if (hEvent)
    SetEvent(hEvent);

  if (hThread)
  {
    _tprintf (_T("Now waiting for thread to terminate...\n"));
    WaitForSingleObject(hThread, INFINITE);
    CloseHandle(hThread);
  }

  if (hEvent)
    CloseHandle(hEvent);

  _tprintf (_T("Done!\n"));
	return 0;
}

Der Code der Exe-Datei erzeugt denselben named Event wie die DLL und startet dann einen Thread mit der Threadfunktion ThreadFunction. Wenn man nun die Aufrufe von Sleep außer acht läßt, dann macht dieser Secondary Thread nichts anderes, als die DLL zu laden. Der Primary Thread unterdessen ermittelt kurz den Pfad zum eigenen Modul mit GetModuleFileName und signalisiert dann den zuvor erzeugten Named Event um schließlich auf die Beendigung des Threads zu warten (dieses Warten hat mit den Race conditions nicht zu tun, es entspringt nur meiner guten Kodierkinderschule).

Man sollte also annehmen, dass der Ablauf des Programms der Folgende ist, was durch die Wahl der Werte für Sleep dem Scheduler von NT quasi nahegelegt wird:

• Die Applikation erzeugt in der Exe-Datei den Named Event.
• Der Thread wird gestartet, aber er legt sich erstmal für 5s schlafen.
• Unterdessen besinnt sich der Code der Exe-Datei erstmal für 2s und schläft, dann ermittelt er seinen eigenen Pfad im Dateisystem (mit GetModuleFileName). Anschließend signalisiert er den Named Event und wartet auf das Terminieren des Threads.
• Wir warten ca. 3s (Gähn!).
• Der Thread lädt die DLL.
• Der C-Runtime Startupcode führt den Konstruktor des globalen Objekts aus. Dieser öffnet nur nochmal ein zweites Handle zu dem bereits vorher erzeugten Named Event. Der Code der Exe-Datei hatte ja schon vorher den Event signalisiert, sodaß in der Funktion CreateAndWaitEvent die Wait-Operation ungestreift durchrauscht.
• Die Dll wird wieder entladen und der Thread terminiert.
• Der Code aus der exe, der auf das Terminieren des Threads wartet, kehrt aus seiner Wait-Operation zurück und main kehrt zurück in die C-Runtime.

Insgesamt sieht also das Ganze auf der Konsole so aus:

So, und jetzt spielen wir mal mit den Sleeps und machen aus den 5000 in der Threadfunktion nur noch schlappe 500.

Wenn wir jetzt den Prozeß erneut starten, stellen wir nach kürzester Zeit fest, daß sich der Prozeß nur noch durch höhere Gewalt beenden läßt. Schnell einen Debugger attacht und die Callstacks der Threads angeschaut. Und da stellt man dann Erstaunliches fest:

• Der Secondary Thread steht in der Wait-Operation in der DLL und wartet darauf, daß der Named Event signalisiert wird.
• Der Primary Thread ist im API GetModuleFileName steckengeblieben.

Ja, aber was ist denn hier passiert? Der Primary Thread kommt nie dazu, den Named Event zu signalisieren, weil er im API GetModuleFileName stecken bleibt. Der komplette Prozeß ist damit hoffnungslos im Deadlock, aber warum denn nur?

Es liegt daran, daß der Secondary Thread, der die DLL lädt, den "Loader Lock", den NT intern zur Serialisierung der DLL-Ladevorgänge einsetzt, für die Zeitdauer der LoadLibrary-Operation hat, aber das GetModuleFileName API diesen Lock halt dummerweise auch braucht.

Wenn man nun das Makro USE_GLOBAL_OBJECT auf 0 stellt, ändert sich am ganzen Verhalten nichts, denn Code, der beim Process Attach ausgeführt wird, unterscheidet sich praktisch in nichts von Code, der im Konstruktor eines globalen Objekts ausgeführt wird.

Und jetzt wird vielleicht auch klar, warum zu DllMain in der MSDN-Dokumentation folgendes steht:

Das ist doch echt verständlich, oder? Und trotzdem sehe ich täglich nichttriviale globale Objekte, superkomplizierten DllMain-Code und andere Grausamkeiten und Fahrlässigkeiten, wie bespielsweise beliebig aufgerufene Funktionen mit Hilfe von Message-Passing-Patterns, wo weiß Gott was passieren kann (SCNR DEI!). Man mag das Ganze nun abtun als Spezialität von GetModuleFileName, aber es fallen natürlich statt GetModuleFileName noch viele weitere APIs darunter, darunter LoadLibrary selber und natürlich sämtliche erstmalige Aufrufe in eine gedelayloadete DLL. Allesamt Dinge, die ganz unschuldig mal so in den Code reinrutschen können, ohne daß jemand was Böses ahnt.

Die Moral von der Geschicht: Mach eine komplizierte DllMain nicht. Benutze ein Minimum an globalen Variablen und schon gar keine globalen Objekte. Wer's trotzdem tut sollte mit Codemaintenance nicht unter drei Jahren belohnt werden.

Über den Loader Lock hat übrigens Michael Grier hier so einiges geschrieben und gleich eine ganze Serie von Blogposts gemacht.

DISCLAIMER: Ein naiver Beobachter könnte nun meinen, ich sei ein Advokat des Einsatzes von Sleep zur Threadsynchronisation. Wer so denkt, sollte erwachsen werden und hat leider nichts verstanden und sollte mal dieses hier lesen und natürlich Fachliteratur wie den Tanenbaum und andere Classics.