Chr. Vogt, FH München 1

Transkript

1 1 Was ist Systemprogrammierung? Windows-Programmierung Konsolenbasierte Programme GUI-Programme Das Win32 Application Programming Interface Win32-Plattformen Erlernen von Win Die Microsoft Development Library (MSDN) Bücher Win32 Header-Dateien Format der Win32-API-Dokumentation Fehlerbehandlung Objekte und Handles Objekte Arten von Objekten Benannte Objekte Handles Öffnen und Schließen von Handles Vererbung und Duplikation von Handles Pseudohandles Prozesse und Threads Erzeugen von Prozessen Beenden von Prozessen Weitere Funktionen für Prozesse Erzeugen von Threads Beenden von Threads Weitere Funktionen für Threads Synchronisation Warten auf Synchronisationsobjekte Critical Sections Mutexe Semaphore Events Waitable Timer Funktionen für atomare Operationen Asynchrone I/Os Anfordern asynchroner I/Os Synchronisation mit der I/O-Beendigung APCs als I/O-Beendigungsroutine I/O Completion Ports...44 Chr. Vogt, FH München 1

2 1 Was ist Systemprogrammierung? Eine häufig sehr hilfreiche erste Informationsquelle, der Duden Informatik, schweigt sich unter diesem Stichwort aus. Es gibt keine einheitliche Definition des Begriffes Systemprogrammierung. In der Windowsund Unix-Welt versteht man darunter das, was der Name nahelegt: die Programmierung unter Verwendung von Systemaufrufen, also offengelegten Schnittstellen zu Routinen des Betriebssystems. In der IBM- Mainframe-Welt (MVS, z/os) versteht man darunter eher die Systemverwaltung. Vielleicht nicht gerade das Einrichten eines Druckers, aber viele andere Aufgaben der Systemverwaltung erfordern dort eine systemnahe (Assembler-)Programmierung. Dies erklärt, warum in dieser Welt für Systemverwaltungsaufgaben der Begriff Systemprogrammierung verwendet wird. In der Windows-Welt wie auch unter den verschiedenen Unix-Derivaten stehen für die meisten Aufgaben der Systemverwaltung mächtige Dienstprogramme zur Verfügung, so dass hier für diese Aufgaben eine (systemnahe) Programmierung nicht notwendig ist. (Unter Unix heißt dieses mächtige Dienstprogramm in sehr vielen Fällen vi.) Im Wesentlichen wollen wir in dieser Vorlesung deshalb unter Systemprogrammierung (im Umfeld von Windows) die Verwendung von systemnahen Funktionen in Programmen verstehen. Daneben würde ich aber auch einige Aufgaben der Systemverwaltung unter diesen Begriff einordnen, für die keine oder nur sehr rudimentäre Dienstprogramme zur Verfügung stehen, und die Kenntnisse über Interna des Betriebssystems erfordern, z.b. den Umgang mit der Registrierungsdatenbank. Auch das Installieren, Konfigurieren und Aktualisieren des Betriebssystems und sonstiger Software, oder anspruchsvolle, fortgeschrittene Aufgaben wie das (hoffentlich selten nötige) Auswerten von Blue Screens würde ich unter den Begriff der Systemprogrammierung einordnen. Die Systembeobachtung und das Tunen des Systems sind ebenfalls Aufgaben, für die zwar Dienstprogramme zur Verfügung stehen, die aber nicht per Kochrezept, sondern nur mit einem hinreichend tiefen Verständnis der Vorgänge am System ausgeführt werden können. Meine Privat-Definition von Systemprogrammierung lautet deshalb: Alle Aufgaben der Programmierung und der Systemverwaltung (Installation, Konfiguration, Systembeobachtung und System-Tuning), die mehr oder weniger tiefe und fundierte Kenntnisse des internen Aufbaus des Betriebssystems erfordern. In diesem Sinne werden wir uns in dieser Vorlesung einige Rosinen der Systemprogrammierung näher betrachten. Auf jeden Fall werden dazu die Programmierung unter Verwendung von (System-)Routinen für den Umgang mit Prozessen und Threads sowie die verschiedenen Synchronisationsmechanismen gehören. Chr. Vogt, FH München 2

3 2 Windows-Programmierung Ein Programm, das Sie z.b. an einem Unix-System von einem Terminal aus starten, läuft an einer bestimmten Stelle los (ein C-Programm mit der Routine main()) und führt dann die im Programm stehenden Anweisungen der Reihe nach aus. Ein- und Ausgaben geschehen dann, wenn das Programm eine entsprechende Anweisung enthält und ausführt. Die Benutzerschnittstelle besteht also aus Textein- und -ausgaben zu den vom Programm vorgesehenen Zeitpunkten. Ein solches Programm wird auch als prozedural bezeichnet. Ein Programm unter Windows läuft üblicherweise ganz anders ab. Sie kennen alle das typische Aussehen eines Windows-Programms mit Fenstern, Menüs, Schaltflächen usw. Unabhängig vom momentan ausgeführten Programmcode können Sie Schaltflächen betätigen, Menüs öffnen und Menüpunkte auswählen, zu einem anderen Fenster (Programm) wechseln oder Fenster schließen usw. Das Programm muß dann geeignet auf diese asynchronen Eingaben reagieren. Man spricht in diesem Zusammenhang von ereignisorientierter Programmierung. Häufig ist ein Programm einfach in einem Wartezustand und wartet auf das nächste Ereignis. Win32 unterstützt zwei prinzipielle Arten von Programmen: Konsolenbasierte Programme (CUI = console user interface) Programme mit einer grafischen Oberfläche (GUI = graphical user interface) 2.1 Konsolenbasierte Programme Ein konsolenbasiertes Programm ähnelt einem Programm, wie Sie es z.b. auch unter Unix verwenden würden: der Programmablauf ist prozedural, Ein- und Ausgaben geschehen nur aufgrund entsprechender Anweisungen im Programm. Aber wo geschehen diese Ein- und Ausgaben? Auch ein konsolenbasiertes Programm benötigt ein Fenster, die sog. Konsole, das jedoch nur herkömmliche Textzeichen enthält (wie z.b. das MS/DOS-Fenster unter Windows). Aber auch für ein Konsolfenster sind natürlich gewisse Ereignisse möglich. Das Fenster kann z.b. verkleinert oder vergrößert oder ganz geschlossen werden. Um diese Standard-Fensterverwaltung kümmert sich das Windows-Betriebssystem und beendet z.b. beim Schließen eines Konsolfensters das entsprechende Programm (das hoffentlich darauf vorbereitet ist...). Und wer erzeugt das Konsolfenster beim Starten des Programms? Ein in der EXE-Datei gespeicherter Subsystem-Wert enthält die Information, ob es sich bei dem Programm um eine konsolenbasierte oder um eine GUI-Anwendung handelt. Im Falle einer konsolenbasierten Anwendung sorgt der Lader dafür, dass für das Programm ein Konsolfenster erzeugt wird. Eine GUI-Anwendung dagegen wird direkt geladen, da sie ja die benötigten Fenster in ihrem Programmcode selbst erzeugt. Wenn Sie beim Erzeugen eines Programms mit Visual C++ oder Borland C++ angeben, dass es sich um eine konsolenbasierte Anwendung handeln soll, wird ein Linker-Schalter gesetzt, so dass der Subsystem-Wert in der EXE-Datei auf CUI gesetzt wird. Das Programm muß dann eine main()-funktion enthalten, die von der Startup-Routine crt0 der Laufzeitbibliothek angesprungen wird. Sie können also Ihr Programm genau so schreiben, wie Sie es aus einer Nicht-Windows-Umgebung gewöhnt sind. Chr. Vogt, FH München 3

4 2.2 GUI-Programme Bei einem GUI-Programm wird von der Startup-Routine wincrt0 der Laufzeitbibliothek die Funktion WinMain aufgerufen. Der Prototyp von WinMain ist etwas komplizierter. Er soll uns hier nicht näher interessieren, da die Entwicklungsumgebungen diesen Teil des Programms automatisch erzeugen. GUI-Programme werden weiter unterteilt in die folgenden drei Arten von Anwendungen: Single Document Interface (SDI) Multiple Document Interface (MDI) Dialogbasierte Anwendungen SDI- und MDI-Anwendungen dienen wie schon der Name sagt der Bearbeitung von Dokumenten. Beispiele für SDI-Anwendungen sind die Editoren Notepad und WordPad von Windows: Sie können immer nur ein Dokument bearbeiten. Beim Öffnen eines neuen Dokuments wird das zuvor geöffnete Dokument geschlossen. Beispiele für MDI-Anwendungen sind übliche Textverarbeitungen oder Tabellenkalkulationen oder auch Paint usw. Sie können dort mehrere Dokumente öffnen, die jeweils in einem eigenen Fenster innerhalb des Anwendungsfensters dargestellt werden, und können beliebig zwischen den einzelnen Dokument-Fenstern hin- und herwechseln. Dialogbasierte Anwendungen sind Programme, deren Hauptprogrammfenster eine Dialogbox ist. In einer solchen Anwendung werden keine Dokumente bearbeitet, sondern andere Funktionen ausgeführt (z.b. Berechnungen), wobei die Steuerung der Funktionen mit Hilfe der Dialogbox, also mit Eingabefeldern, Schaltflächen, Menüs usw. geschieht. Die meisten Verwaltungsprogramme von Windows (Benutzermanager, Systemmonitor usw.) sind solche dialogbasierten Anwendungen. Die Gestaltung des Dialogfensters ist mit Hilfe der Entwicklungsumgebung sehr einfach. Es gibt einen Ressourcen-Editor, mit dem Sie das Fenster gestalten können, ohne eine einzige Zeile Code zu schreiben und somit ohne etwas über die Art der Implementierung der verschiedenen Elemente wissen zu müssen. Wie hängen aber jetzt die einzelnen Elemente des Dialogfensters mit dem Programm zusammen? Dazu gehören zwei Dinge: 1. Ein- und Ausgabefelder müssen mit Variablen des Programms verknüpft werden. 2. Für jede mögliche Aktion, z.b. das Klicken auf eine Schaltfläche, muß eine Behandlungsroutine geschrieben werden. Bei beiden Aufgaben unterstützt Sie wieder die Entwicklungsumgebung. Um vieles müssen Sie sich überhaupt nicht kümmern, z.b. um die (programmtechnische) Verknüpfung der Aktionen im Dialogfenster mit den von Ihnen geschriebenen Routinen. Chr. Vogt, FH München 4

5 3 Das Win32 Application Programming Interface Das Win32 Application Programming Interface (API) ist die wichtigste Schnittstelle zum Betriebssystem Windows. Obwohl Windows auch andere APIs unterstützt (z.b. POSIX und OS/2, allerdings nicht mehr ab Windows XP), bietet das Win32 API Zugriff auf den größten Teil der Möglichkeiten, die Windows bietet. So enthält z.b. das POSIX-Subsystem keine Funktionen für Multithreading oder asynchrone Ein-/Ausgaben. Das Win32 API besteht aus drei Hauptgruppen von Funktionen: Base System Services User Services (Windows management) Graphics device interface (GDI) Services Die Base System Services bieten Zugriff auf Funktionen des Betriebssystems, wie z.b. den Umgang mit Prozessen und Threads, die Speicherverwaltung, die Durchführung von Ein-/- Ausgaben oder das Verwenden von Sicherheitsmechanismen. Mit einigen dieser Funktionen werden wir uns in dieser Vorlesung beschäftigen. Bemerkung: Die Base System Services sind nicht die eigentlichen Systemaufrufe des Betriebssystems. Letztere wurden von Microsoft nicht offengelegt, so dass nur über die dokumentierten Subsystem-APIs, also z.b. das Win32-API, auf sie zugegriffen werden kann. Die User Services beinhalten Funktionen zur Gestaltung der Benutzerschnittstelle, also für die Verwaltung von Fenstern und von Tastatur- und Mauseingaben. Mit Hilfe der GDI Services können Applikationen grafische Ausgaben erzeugen. Keine dieser Funktionen wird in dieser Vorlesung behandelt. Die Gestaltung der Benutzerschnittstelle wird durch Compiler wie Borland C++ oder Microsoft Visual C++ stark vereinfacht, und der dafür notwendige Code größtenteils automatisch generiert. Insgesamt besteht das Win32 API aus über 1500 Funktionen! 3.1 Win32-Plattformen Das Win32 API ist die Spezifikation einer Programmierschnittstelle. Diese Schnittstelle oder Teilmengen davon sind nicht nur auf Windows NT / 2000 / XP implementiert, sondern auf insgesamt sechs Plattformen: Windows 3.1 (mit den Win32s-Bibliotheken). Bietet dieselbe Funktionalität wie Windows 3.1, aber mit der 32-bit-Programmierschnittstelle. Bietet darüber hinaus einige Erweiterungen, z.b. einen linearen 32-bit-Adreßraum sowie strukturierte Ausnahmebehandlung. Windows 95 / 98 / ME Bietet den größten Teil der Funktionalität wie unter Windows, aber z.b. keine Funktionen für Sicherheit, event logging oder asynchrone Ein-/Ausgaben. Windows NT / 2000 / XP Macintosh OpenVMS (Angebote von Bristol Technology und Mainsoft Corporation). Die Laufzeit-Bibliotheken von Wind/U von Bristol sind sogar in VMS enthalten. Unix (Angebote von Bristol Technology und Mainsoft Corporation). Chr. Vogt, FH München 5

6 3.2 Erlernen des Win32 API Die Microsoft Developer s Network Library Die Microsoft Developer s Network (MSDN) Library ist eine regelmäßige CD-ROM- Distribution, die (für teures Geld) abonniert werden kann. Wenn man nur kleine Teile daraus benötigt, findet man sie aber auch im Internet unter msdn.microsoft.com/library/. In der MSDN Library findet man die gesamte Win32-API-Dokumentation, die Win32 Knowledge Base, eine Problemdatenbank, jede Menge Beispielprogramme, viele technische Artikel. Die Fülle der Informationen in der MSDN ist erschlagend. Leider ist die Strukturierung nicht allzu übersichtlich, so dass es einige Zeit und Mühe kostet, die Informationen zu finden, die einen interessieren. Aber vorhanden sind sie höchstwahrscheinlich! Für unsere Vorlesung am interessantesten und am wichtigsten ist der Abschnitt Windows Development -> Windows Base Services. Die meisten Unterabschnitte gliedern sich wiederum in SDK Documentation und Technical Articles Bücher Außerdem gibt es natürlich diverse Bücher zum Win32-API. Ein Buch, das als Begleitung zur Vorlesung gut geeignet ist (mit seinen über 1000 Seiten aber auch noch jede Menge weitere Informationen enthält) ist: Jeffrey M. Richter: Windows Programmierung für Experten, 4. Auflage 2000, Microsoft Press Deutschland Es kann gut sein, dass eines der Beispielprogramme aus diesem Buch Ihnen in der Vorlesung bzw. im Praktikum wieder begegnet. Weitere Bücher mit derselben Zielsetzung, aber unterschiedlicher Stoffauswahl und Darstellung sind: Marshall Brain: Win32 System Services, 3 rd ed., Prentice Hall 2001 Johnson M. Hart: Win32 System Programming, 2 nd ed., Addison-Wesley 2000 Von Jeffrey M. Richter gibt es auch noch das Buch Microsoft.NET Framework Programmierung, Microsoft Press Chr. Vogt, FH München 6

7 3.2.3 Win32 Header-Dateien Die Win32-API-Header-Dateien enthalten Informationen über vorhandene Konstanten und Strukturen sowie Details der Programmierschnittstelle. Es handelt sich um viele kleine Dateien, die alle von der Datei Windows.h referenziert werden. Zum Beispiel enthält die Datei WinBase.h die Definitionen der Base System Services. Wenn Sie mit Visual Studio.NET 2003 arbeiten, finden Sie die Header-Dateien in \Vc7\PlatformSDK\include unterhalb des Wurzelverzeichnisses für Visual Studio. Da Sie in den Praktikumsaufgaben mit den Base System Services arbeiten werden, sollten Sie in Ihren Programmen immer Windows.h inkludieren. Manchmal ist es auch interessant, sich die eine oder andere Definition oder Deklaration in einer der Header-Dateien direkt anzuschauen Format der Win32-API-Dokumentation Die Dokumentation einer Win32-API-Funktion enthält Angaben über Bedeutung und Datentyp der Parameter und des Rückgabewertes der Funktion. Ein typisches Beispiel: DWORD WaitForMultipleObjects( DWORD ncount, CONST HANDLE *lphandles, BOOL bwaitall, DWORD dwmilliseconds // number of handles in the object handle array // pointer to the object-handle array // wait flag // time-out interval in milliseconds Die Angabe DWORD in der ersten Zeile ist der Datentyp des Rückgabewertes der Funktion, in diesem Falle ein double word. Außerdem enthält die erste Zeile den Namen der Funktion (fett). Die folgenden Zeilen enthalten den Datentyp (DWORD, BOOL usw.) (fett) der einzelnen Parameter, den Parameternamen (kursiv) und einen Kommentar, der den Parameter beschreibt. Der Parameter wird in der sog. ungarischen Notation geschrieben (die Bezeichnung kommt von der ungarischen Abstammung des Microsoft-Entwicklers, der diese Notation erfunden hat): datatypeparametername So ist z.b. der Parameter ncount vom Datentyp n (number lphandles ist ein longword pointer auf ein Feld von Handles. Einige gebräuchliche Datentypen sind: Zeichen c b n b oder f w l dw p fn sz lph Datentyp char oder count BYTE (unsigned char) short oder int BOOL (int) WORD (unsigned int) LONG (long) DWORD (unsigned long) pointer function mit 0 abgeschlossene Zeichenkette (string, zero terminated) long pointer auf ein Handle Chr. Vogt, FH München 7

8 Natürlich enthält die Dokumentation einer Funktion neben der oben angegebenen Kurzform auch noch ausführlichere Erläuterungen, z.b. zu der Funktionalität der Funktion, der Bedeutung von und den möglichen Angaben für die Parameter, dem Rückgabewert der Funktion, evtl. Einschränkungen (z.b. benötigten Rechten) oder Vorsichtsmaßnahmen, den Windows-Versionen, unter denen die Funktion zur Verfügung steht, den Header-Dateien und Bibliotheken, die für die Funktion benötigt werden Fehlerbehandlung Es gibt keine standardisierte Methode um festzustellen, ob die Ausführung einer Funktion einen Fehler produzierte. Einige Funktionen geben bei Erfolg eine 0 zurück, andere geben bei einem Fehler eine 0 zurück, andere erzeugen einfach einen Rückgabewert. Die meisten Funktionen geben bei einem Fehler NULL zurück und sagen, dass man GetLastError aufrufen soll, um den Grund für den Fehler herauszufinden. DWORD GetLastError(VOID) Auf den von GetLastError zurückgegebenen Fehlercode kann dann die Applikation geeignet reagieren, oder der Code kann mit FormatMessage in einen Nachrichtentext umgewandelt und z.b. ausgegeben werden. Leider gibt die Dokumentation einer Funktion jedoch nicht an, welche Fehlercodes von dieser Funktion erzeugt werden können. Ohne auf die einzelnen Parameter einzugehen hier ein Beispiel für die Verwendung von FormatMessage: FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM, // System Message Table verwenden NULL, GetLastError(), 0, (LPTSTR) &lpmsgbuf, // Zeiger auf einen Puffer 200, // Größe des Puffers NULL In Visual Studio gibt es eine einfache Möglichkeit, zu einem numerischen Fehlercode eine Kurzbeschreibung zu erhalten: wählen Sie einfach im Menü Tools den Punkt Error Lookup. Die Header-Datei WinError.h enthält eine Liste von über 400 solchen Fehlercodes. Das Format eines Fehlercodes wird dort wie folgt beschrieben: Chr. Vogt, FH München 8

9 // Values are 32 bit values layed out as follows: // // // // // Sev C R Facility Code // // // where // // Sev - is the severity code // // 00 - Success // 01 - Informational // 10 - Warning // 11 - Error // // C - is the Customer code flag // // R - is a reserved bit // // Facility - is the facility code // // Code - is the facility's status code Gemäß dieser Beschreibung gibt das oberste Bit also an, ob die Funktion erfolgreich durchgeführt werden konnte (0 für Success oder Information) oder ob ein Fehler aufgetreten ist (1 für Warning oder Error). In Wirklichkeit steht in den obersten 16 Bit der Fehlercodes eine 0. (Oder liefert GetLastError nur die unteren 16 Bit?) Für jeden einzelnen Fehlercode folgt dann ein Eintrag wie z.b. der folgende: // MessageId: ERROR_INVALID_HANDLE // // MessageText: // // The handle is invalid. // #define ERROR_INVALID_HANDLE 6L In der MSDN finden Sie eine Liste der Error-Codes unter Windows Development -> Windows Base Services -> Debugging and Error Handling -> SDK Documentation -> Error Handling -> System Error Codes (wo sonst hätten Sie auch gesucht ). Chr. Vogt, FH München 9

10 4 Objekte und Handles Um die Win32 Base System Services zu verwenden, müssen Sie die Konzepte von Objekten und Handles verstehen. Gemeinsam benutzbare System-Ressourcen werden von Windows als Objekte implementiert. Um auf ein Objekt zuzugreifen, muß ein Prozess zunächst ein Handle auf dieses Objekt anfordern ( öffnen ). 4.1 Objekte Ein Objekt ist eine Datenstruktur mit bestimmten Eigenschaften, die gemeinsam benutzbare System-Ressourcen repräsentiert, wie z.b. Dateien, Prozesse oder Geräte. Es gibt zwei Hauptgründe, warum System-Ressourcen als Objekte implementiert werden: 1. Microsoft kann die Funktionalität von Windows verbessern, solange die Schnittstelle zu den Objekten unverändert bleibt. 2. Die Benutzung von Objekten ermöglicht die Nutzung der Sicherheitsmerkmale von Windows. Jedes Objekt hat eine Access Control List (ACL), die festlegt, welcher Prozess welche Aktionen mit dem Objekt ausführen darf. Ein Objekt besteht aus einem Standard-Kopf und objekttypspezifischen Attributen. Der Objekt-Kopf enthält z.b. den Namen des Objekts und einen Sicherheits-Beschreiber. Da alle Objekte die gleiche grundlegende Struktur haben, gibt es nur einen einzigen Objekt-Manager, der alle Objekte handhabt. Zu den Aufgaben des Objekt-Managers gehören Das Erzeugen von Objekten. Die Überprüfung, ob ein Prozess das Recht hat, ein Objekt zu benutzen. Das Erzeugen (Öffnen) und Schließen von Handles zu einem Objekt (s.u.). Das Verwalten von Quoten für Ressourcen. Das Win32-API enthält Funktionen für die folgenden Aufgaben: Das Erzeugen von Objekten. Das Erzeugen von Handles zu einem Objekt. Das Einholen von Informationen über ein Objekt. Das Setzen von Informationen (Attributen) eines Objekts. Das Schließen eines Handles zu einem Objekt. Objekte und Handles zu Objekten verbrauchen Speicher. Deswegen ist es wichtig, nicht mehr benötigte Handles zu schließen und nicht mehr benötigte Objekte aus dem System zu entfernen. Wenn ein Prozess endet, schließt das System automatisch seine Handles und entfernt Objekte, die nur noch von diesem Prozess genutzt wurden. Dies geschieht jedoch nicht bei der Beendigung eines einzelnen Threads (außer wenn dies der letzte Thread des Prozesses ist, und somit auch der Prozess beendet wird). Chr. Vogt, FH München 10

11 4.1.1 Arten von Objekten Unter Windows gibt es drei Arten von Objekten: User Objekte GDI (graphics device interface) Objekte Kernel-Objekte User Objekte sind z.b. Fenster und Menüs, GDI Objekte Bitmaps oder Fonts. In dieser Vorlesung interessieren uns nur die Kernel-Objekte. Zu diesen gehören: Prozesse und Threads, Events, Mutexes, Semaphore und Timer (für die Synchronisation), Mailslots und Pipes (für die Kommunikation), Dateien File mappings und Heaps (für die Speicherverwaltung). Der Begriff Kernel-Objekte ist etwas irreführend, da nicht alle diese Objekte auch Objekte des Betriebssystem-Kernels sind. So sind z.b. Mailslots und Pipes Erfindungen des Win32- Subsystems, von denen der Kernel des Betriebssystems nichts weiß Benannte Objekte Die einfachste Methode, um Kernel-Objekte über mehrere Prozesse hinweg zu verwenden, liegt im Benennen der Objekte. Nicht alle, aber viele der Kernel-Objekte lassen sich benennen. Für benennbare Objekte hat die entsprechende Createxxx-Funktion einen Parameter lpszname, für den die Adresse eines durch eine 0 abgeschlossenen Strings angegeben werden kann. Andere Prozesse können dann mit einer Openxxx-Funktion unter Angabe des Namens ein Handle zu diesem Objekt öffnen. Zu beachten ist, dass all diese Objekte sich einen gemeinsamen, systemweiten Namensraum teilen. Bei der Namensvergabe sollte man also vorsichtig sein und sich am besten vorab eine vernünftige Konvention überlegen. 4.2 Handles Applikationen können Objekte mit Hilfe von API-Funktionen manipulieren. Da der Zugriff auf die Datenstrukturen eines Kernel-Objekts nur dem Betriebssystem-Kernel möglich ist, müssen sie dazu allerdings erst ein sog. Handle zu dem Objekt anfordern ( öffnen ). Jeder Prozess hat eine Handle-Tabelle. Diese wird nur für Kernel-Objekte, nicht aber für User- oder GDI-Objekte verwendet. Die Handle-Tabelle ist prozessweit und steht somit allen Threads eines Prozesses gleichermaßen zur Verfügung. In der Handle-Tabelle stehen u.a. die Zeiger auf die Datenstrukturen des Kernels für die Objekte. Der Handle-Wert mit dem ein Prozess bzw. seine Threads arbeiten, ist einfach ein 32-bit-Wert, der als Index in diese Chr. Vogt, FH München 11

12 Tabelle verwendet wird. Als Datentyp sollte die Angabe HANDLE verwendet werden, die in den Header-Dateien definiert wird. Beim Erzeugen oder Öffnen eines Objekts wird ein freier Eintrag in der Handle-Tabelle des Prozesses gesucht, und der entsprechende Index als Handle-Wert zurückgegeben. Jedes Objekt enthält einen Zähler für die von Prozessen geöffneten Handles für dieses Objekt, einen weiteren Zähler für die Referenzen des Betriebssystems auf dieses Objekt. Ein Objekt wird dann, und erst dann, automatisch vom System entfernt, wenn diese beiden Zähler auf Null gehen Öffnen und Schließen von Handles Ein Prozess öffnet ein Handle zu einem Objekt, indem er ein neues Objekt mit einer objekttyp-spezifischen Createxxx-Funktion erzeugt, oder indem er ein existierendes Objekt mit einer objekttyp-spezifischen Openxxx-Funktion öffnet. Bei dem Versuch, ein benanntes Objekt zu erzeugen, das bereits existiert, wird das vorhandene Objekt geöffnet und ein Handle zurückgegeben. In diesem Fall ist der Rückgabewert von GetLastError der Code ERROR_ALREADY_EXISTS. Ein Handle wird mit der Win32-API-Funktion CloseHandle wieder geschlossen. Gibt es zu einem Objekt kein Handle mehr, und wird das Objekt auch vom Betriebssystem nicht mehr verwendet, so wird das Objekt selbst automatisch entfernt Vererbung und Duplikation von Handles Handles können von einem Prozess, der mit CreateProcess neu erzeugt wird, geerbt werden. Außerdem können Handles für die Benutzung durch einen anderen Prozess dupliziert werden. In beiden Fällen besteht das Problem, dass der neue bzw. andere Prozess zunächst nichts von den Handles weiß, die ihm auf einmal zur Verfügung stehen. Also muß ihm dies auf irgendeine Art und Weise mitgeteilt werden Vererbung von Handles Beim Öffnen eines Handles zu einem Objekt kann angegeben werden, dass dieses Handle von später erzeugten Prozessen geerbt werden kann. Einige Funktionen haben dafür einen Parameter inheritable (= vererbbar), bei den meisten Funktionen muß dies jedoch in einem Flag in dem Parameter SECURITY_ATTRIBUTES angegeben werden. Die Struktur SECURITY_ATTRIBUTES ist wie folgt definiert: Chr. Vogt, FH München 12

13 typedef struct _SECURITY_ATTRIBUTES { // sa DWORD nlength; LPVOID lpsecuritydescriptor; BOOL binherithandle; } SECURITY_ATTRIBUTES; Die Boole sche Variable binherithandle gibt dabei an, ob das Handle vererbbar ist (TRUE) oder nicht (FALSE). nlength muß die Größe der Struktur in Bytes enthalten (sizeof(...)). SecurityDescriptor ist eine Struktur, die Sicherheitsinformationen für das Objekt enthält, auf die wir hier nicht eingehen wollen. Vererbbare Handles werden nicht automatisch bei der Erzeugung eines Prozesses mit CreateProcess vererbt, sondern nur, wenn der Parameter InheritHandle auf TRUE gesetzt wird. In diesem Fall werden die Einträge der Handle-Tabelle des Vater-Prozesses, die vererbbare Handles beschreiben, in die Handle-Tabelle des neu erzeugten Sohn- Prozesses kopiert, und zwar an genau dieselbe Position wie in der Ursprungstabelle. Der erzeugte Prozess weiß dann allerdings noch nichts von den Handles, die er geerbt hat. Eine Möglichkeit, ihm dies mitzuteilen ist, die Handle-Werte, die ja in beiden Prozessen gleich sind, als ASCII-String in dem Parameter CommandLine der CreateProcess-Funktion zu übergeben (siehe auch das Kapitel über Prozesse und Threads) Duplizieren von Handles Ein Prozess kann eine Kopie eines existierenden Handles an einen anderen Prozess weiterreichen. Dies wird mit der Funktion DuplicateHandle erreicht. Als erstes müssen Quell- und Zielprozess geöffnet werden (mit OpenProcess). Danach kann das Handle übergeben werden mit BOOL DuplicateHandle( HANDLE hsourceprocesshandle, HANDLE hsourcehandle, HANDLE htargetprocesshandle, LPHANDLE lptargethandle, // handle to duplicate // pointer to duplicate handle (Weitere mögliche Parameter wurden weggelassen.) Es können hier insgesamt drei verschiedene Prozesse involviert sein: der Prozess, der DuplicateHandle aufruft, der Quellprozess, von dessen Handles einer dupliziert wird der Zielprozess, der das duplizierte Handle erhält. Zu beachten ist auf jeden Fall die Bedeutung der verschiedenen Handle-Angaben: die Angaben für den Quell- und den Zielprozess sind natürlich aus Sicht des Aufrufers von DuplicateHandle. Der zweite Parameter (hsourcehandle) bezieht sich auf ein Handle im Quellprozess, und der vierte Parameter (lptargethandle) enthält die Adresse einer Handle-Variablen, die den Index des Eintrags in der Handle-Tabelle des Zielprozesses aufnimmt, in den das duplizierte Handle geschrieben wird. Diese Angabe bezieht sich dann also auf den durch lptargetprocesshandle identifizierten Prozess. (Ufff...). Danach muß noch, mit Hilfe irgendeiner Interprozess-Kommunikationsmethode, dem Zielprozess mitgeteilt werden, mit welchem Handle-Wert er dieses duplizierte Handle ansprechen kann. Chr. Vogt, FH München 13

14 Wie man sieht ist die Sache nicht so ganz einfach. Dies ist ein weiterer Grund, lieber mit mehreren Threads innerhalb eines Prozesses zu arbeiten, die sich ja automatisch alle Handles teilen. Und um ein Objekt von mehreren Prozessen aus zu benutzen, ist es in der Regel einfacher, mit benannten Objekten zu arbeiten, als Handles zu duplizieren. Eine mögliche weitere Anwendung von DuplicateHandle besteht darin, für ein Objekt ein Handle mit anderen Zugriffsanforderungen zu erhalten: Man dupliziere ein schon vorhandenes Handle in den eigenen Prozess unter Angabe des gewünschten Zugriffs (Parameter dwdesiredaccess) und schließe das ursprüngliche Handle (oder gebe für den Parameter dwoptions von DuplicateHandle den Wert DUPLICATE_CLOSE_SOURCE an). Auch die Eigenschaft eines Handles, vererbbar zu sein oder nicht, kann auf diese Art geändert werden (Parameter binherithandle). Einfacher ist in diesem Fall aber die Benutzung der Funktion SetHandleInformation. Ein weiteres Beispiel für die Verwendung von DuplicateHandle ist die Situation, in der zwei Threads eines Prozesses dasselbe Objekt verwenden. Wenn beide Threads mit der Arbeit fertig sind, soll das Objekt entfernt werden. Da aber keiner der Threads weiß, ob der andere bereits mit seiner Arbeit fertig ist, verwenden die Threads zwei unterschiedliche Handles. Jeder Thread schließt sein Handle, sobald er das Objekt nicht mehr braucht. Wenn beide Handles geschlossen wurden, wird das Objekt automatisch vom System entfernt. (Natürlich kann man das zweite Handle auch mit einer Openxxx Funktion erhalten.) Pseudohandles Häufig ist es nötig, ein Handle für den eigenen Prozess oder Thread anzugeben, z.b. beim Einholen von Prozess-Informationen mit GetProcessxxx-Funktionen oder dem Ändern von Prozesseigenschaften mit SetProcessxxx-Funktionen, oder beim Duplizieren eines Handles des momentanen Prozesses, wobei der Quellprozess identisch ist mit dem Prozess, der DuplicateHandle aufruft. Als Handle-Angabe für den aktuellen Prozess bzw. Thread können in all diesen Fällen die Funktionen HANDLE GetCurrentProcess(VOID) HANDLE GetCurrentThread(VOID) verwendet werden. Diese liefern jedoch nur sog. Pseudohandle. Ein Pseudohandle kann (und braucht somit) nicht wieder geschlossen werden, und kann nicht vererbt werden. Wenn ein Thread ein echtes Handle für sich oder seinen Prozess benötigt, z.b. um diesen zu vererben, kann er entweder das Pseudohandle duplizieren (was zu einem echten Handle führt), oder mit OpenThread bzw. OpenProcess unter Angabe der Thread- bzw. Prozess- ID (die er wiederum mit GetCurrentThreadId() bzw. GetCurrentProcessId() bekommen kann) ein Handle zu sich oder zu seinem Prozess erhalten. Chr. Vogt, FH München 14

15 5 Prozesse und Threads In diesem Kapitel betrachten wir einige der Win32-API-Funktionen zum Umgang mit Prozessen und Threads. Die Dokumentation nennt für diesen Bereich 67 Funktionen (plus 12 Funktionen für Fibers und 8 für Jobs), von denen wir nur einige wenige behandeln werden. 5.1 Erzeugen von Prozessen Der Prototyp der Funktion CreateProcess zum Erzeugen eines Prozesses lautet: BOOL CreateProcess( LPCTSTR lpapplicationname, // pointer to name of executable module LPTSTR lpcommandline, // pointer to command line string LPSECURITY_ATTRIBUTES lpprocessattributes, // pointer to process security attributes LPSECURITY_ATTRIBUTES lpthreadattributes, // pointer to thread security attributes BOOL binherithandles, // handle inheritance flag DWORD dwcreationflags, // creation flags LPVOID lpenvironment, // pointer to new environment block LPCTSTR lpcurrentdirectory, // pointer to current directory name LPSTARTUPINFO lpstartupinfo, // pointer to STARTUPINFO LPPROCESS_INFORMATION lpprocessinformation //pointer to PROCESS_INFORMATION Das bedarf sicher noch ein paar Erklärungen. Fangen wir mit der Beschreibung der Funktion an. Vielleicht haben Sie sich bereits über den Parameter lpthreadattributes gewundert, wo wir doch einen Prozess erzeugen wollen. Nun, beim Erzeugen eines Prozesses geschieht folgendes: 1. Das Betriebssystem erzeugt ein internes Prozessobjekt. 2. Das Betriebssystem erzeugt einen 4 GB großen virtuellen Adreßraum für den neuen Prozess und lädt ihn mit dem Programmcode und den Daten der ausführbaren Datei. 3. Das Betriebssystem erzeugt ein internes Threadobjekt für den primären Thread des neuen Prozesses. 4. Der primäre Thread beginnt mit der Ausführung der Startroutine der C-Laufzeitbibliothek, die schließlich die main- bzw. WinMain-Funktion aufruft. Kommen wir nun zu einer näheren Betrachtung der Parameter von CreateProcess. Die ersten beiden Parameter, lpapplicationname und lpcommandline dienen der Angabe des Programms, das in dem neuen Prozess ausgeführt werden soll, sowie möglicher weiterer Angaben in der Kommandozeile. Üblicherweise wird für lpapplicationname der Wert NULL übergeben, und die ausführbare Datei für den neuen Prozess als erstes Token (Wort) der Kommandozeile angegeben. Enthält die Dateiangabe keinen Pfad, so wird die Datei in folgenden Verzeichnissen gesucht: 1. Im Verzeichnis, das die EXE-Datei des aufrufenden Prozesses enthält. 2. Im aktuellen Verzeichnis des aufrufenden Prozesses. 3. Im 32-bit-Systemverzeichnis von Windows. 4. Im 16-bit-Systemverzeichnis von Windows. 5. Im Windows-Verzeichnis. 6. In den in der Umgebungsvariablen PATH aufgeführten Verzeichnissen. Chr. Vogt, FH München 15

16 Bemerkung: Wenn hier und im folgenden aufrufender Prozess oder aktueller Prozess steht ist immer der Prozess gemeint, zu dem der aufrufende oder aktuelle Thread gehört. Der Rest der Kommandozeile, nach dem ersten Token, wird an die WinMain-Funktion übergeben und landet schließlich in den globalen Variablen argc und argv. Ein Programm kann aber auch mit der Funktion GetCommandLine einen Zeiger auf die gesamte Kommandozeile erhalten. Die Parameter lpprocessattributes und lpthreadattributes sind Zeiger auf Strukturen vom Typ SECURITY_ATTRIBUTES für den Prozess bzw. seinen primären Thread (der ja gleich miterzeugt wird). Zur Erinnerung: Diese Struktur enthält zwei Angaben: 1. Einen Security Descriptor, der Sicherheitsinformationen für das Objekt angibt. 2. Die Angabe, ob das Handle zu diesem Objekt vererbbar sein soll. Bei Angabe von NULL wird ein Standard-Security-Descriptor verwendet, und das Handle ist nicht vererbbar. Der Parameter binherithandles gibt an, ob vererbbare Handles des aufrufenden Prozesses an den zu erzeugenden Prozess vererbt werden sollen. Der Parameter dwcreationflags enthält einige Flags, die die Erzeugung des neuen Prozesses steuern. Eine vollständige Liste der möglichen Flags finden Sie in der Dokumentation. Zwei wichtige Flags sind: CREATE_NEW_CONSOLE Für Konsolen-Anwendungen: Der neue Prozess erhält ein eigenes Konsolenfenster. Standardmäßig benutzt er das Konsolenfenster des aufrufenden Prozesses mit. CREATE_SUSPENDED Der primäre Thread des Prozesses wird im Zustand SUSPENDED erzeugt und läuft erst nach Aufruf der Funktion ResumeThread los. Außerdem steuert der Parameter dwcreationflags die Prioritätsklasse des neuen Prozesses. Die möglichen Angaben hierfür sind: IDLE_PRIORITY_CLASS NORMAL_PRIORITY_CLASS HIGH_PRIORITY_CLASS REALTIME_PRIORITY_CLASS Standardmäßig wird die NORMAL_PRIORITY_CLASS verwendet (mit Ausnahmen, siehe Doku). Nähere Informationen über Prioritäten finden Sie in der Betriebssystemvorlesung. Die Parameter lpenvironment und lpcurrentdirectory dienen der Angabe eines Bereiches mit Umgebungsvariablen bzw. des Standard-Verzeichnisses für den neuen Prozess. Bei Angabe von NULL erbt der neue Prozess diese Angaben vom aufrufenden Prozess. Der Parameter lpstartupinfo zeigt auf eine Struktur des Typs STARTUPINFO, die vor allem Angaben darüber enthält, wie das Hauptfenster der Applikation aussehen soll (Größe, Position etc.). Um Standardwerte zu verwenden, kann man alle Elemente in der Struktur auf Null setzen und nur das Feld cb mit der Größe der Struktur initialisieren: Chr. Vogt, FH München 16

17 STARTUPINFO si; ZeroMemory(&si, sizeof(si) si.cb = sizeof(si CreateProcess(..., &si,... Last not least: der Parameter lpprocessinformation. Er verweist auf eine Struktur vom Typ PROCESS_INFORMATION, die von der Funktion CreateProcess mit Informationen gefüllt wird. Die Struktur ist folgendermaßen definiert: typedef struct _PROCESS_INFORMATION { // pi HANDLE hprocess; HANDLE hthread; DWORD dwprocessid; DWORD dwthreadid; } PROCESS_INFORMATION; Hier finden wir nun also die Handles für den erzeugten Prozess und für dessen primären Thread und außerdem deren numerische Identifikationen. Die Funktion CreateProcess öffnet also ungefragt je ein Handle zu dem neuen Prozess und seinem primären Thread. Vergessen Sie nicht, diese Handles wieder zu schließen! Wenn der aufrufende Prozess sie überhaupt nicht benötigt, schließen Sie sie am besten sofort nach Aufruf von CreateProcess. Sie wissen ja, dass das Prozess- und das Threadobjekt nicht entfernt werden können, solange noch offene Handles für sie existieren! Nach all diesen Erklärungen jetzt aber schnell ein Beispiel, um zu sehen, dass es gar nicht so kompliziert ist: STARTUPINFO si; PROCESS_INFORMATION pi; // Vorbereiten der STARTUPINFO-Struktur: ZeroMemory(&si, sizeof(si) si.cb = sizeof(si CreateProcess( NULL, // EXE-Datei wird im 2. Argument angegeben "exe_file", // Keine weiteren Angaben in der Kommandozeile NULL, // Standard-Sicherheit, Handle nicht vererbbar NULL, // Standard-Sicherheit, Handle nicht vererbbar FALSE, // Handles nicht vererben 0, // Keine Flags, d.h. u.a. NORMAL_PRIORITY_CLASS NULL, // Umgebungsvariablen "vererben" NULL, // Standard-Verzeichnis "vererben" &si, // STARTUPINFO &pi // PROCESS_INFORMATION // Handles schließen: CloseHandle(pi.hProcess CloseHandle(pi.hThread Chr. Vogt, FH München 17

18 5.2 Beenden von Prozessen Kommen wir nun zum Beenden eines Prozesses. Dies kann auf dreierlei Arten geschehen: 1. Ein Thread im Prozess ruft die Funktion ExitProcess auf. 2. Ein Thread in einem anderen Prozess ruft die Funktion TerminateProcess auf. 3. Alle Threads in einem Prozess arbeiten bis zu ihrem natürlichen Ende. Bei Beendigung des letzten Threads eines Prozesses wird dann automatisch auch der Prozess beendet. Der Aufruf von ExitProcess: VOID ExitProcess( UINT uexitcode // exit code for all threads beendet zunächst alle noch vorhandenen Threads des Prozesses und anschließend den Prozess selbst. Das gleiche geschieht beim Aufruf von TerminateProcess: BOOL TerminateProcess( HANDLE hprocess, UINT uexitcode // handle to the process // exit code for the process wobei dieser Aufruf aber durch Angabe eines Handles auch für einen anderen als den eigenen Prozess durchgeführt werden kann. Im Allgemeinen sollte man jedoch auf die Verwendung von TerminateProcess verzichten, da dabei keine DLLs benachrichtigt werden, was zu einem fehlerhaften Abschluß des Prozesses führen kann. Der Exit-Code, der bei diesen Funktionen angegeben werden kann, kann von anderen Prozessen mit GetExitCodeProcess abgefragt werden. Solange der Prozess noch läuft liefert diese Funktion den Wert STILL_ACTIVE. Bei der Terminierung eines Prozesses geschieht folgendes: 1. Alle Threads des Prozesses beenden ihre Ausführung. 2. Alle vom Prozess reservierten Benutzer- und GDI-Objekte werden freigegeben, und alle Kernel-Objekte werden geschlossen (d.h. die Handles darauf werden geschlossen). 3. Das Prozessobjekt wechselt in den Signalled State (ebenso seine Threadobjekte). 4. Der Exitcode des Prozesses wechselt von STILL_ACTIVE in den Code, der der Funktion ExitProcess bzw. TerminateProcess übergeben wurde. 5. Der interne Benutzerzähler des Prozessobjekts wird um 1 dekrementiert. Wenn ein Prozess terminiert, werden also sein Programmcode und die von ihm reservierten Betriebsmittel aus dem Speicher entfernt. Das ihm entsprechende Prozessobjekt und der dafür benötigte Speicher werden jedoch erst freigegeben, wenn alle noch existierenden Bezüge auf das Objekt (also Handles anderer Prozesse zu diesem Objekt) geschlossen worden sind. Chr. Vogt, FH München 18

19 5.3 Weitere Funktionen für Prozesse Die folgende Tabelle beschreibt kurz einige weitere wichtige Funktionen beim Umgang mit Prozessen. Bei Bedarf oder Interesse lesen Sie bitte Einzelheiten in der Dokumentation nach. GetCurrentProcess GetCurrentProcessId OpenProcess GetPriorityClass SetPriorityClass GetProcessPriorityBoost SetProcessPriorityBoost GetProcessTimes GetProcessWorkingSetSize SetProcessWorkingSetSize Um ein Pseudohandle für den aktuellen Prozess zu erhalten. Um die Process-Identification des aktuellen Prozesses zu erhalten. Um ein Handle zu einem Prozess zu erhalten. Der Prozess wird dabei durch seine Process-Identification angegeben. Abfragen bzw. Ändern der Prioritätsklasse eines Prozesses. Abfragen bzw. Einstellen, ob für alle Threads des Prozesses eine automatische Prioritätenanpassung durch das Betriebssystem gemacht werden soll. Liefert vier Zeitangaben für einen Prozess: Den Erzeugungszeitpunkt des Prozesses. Den Beendigungszeitpunkt des Prozesses. Die Zeit, die alle Threads des Prozesses zusammen im User Mode verbracht haben. Die Zeit, die alle Threads des Prozesses zusammen im Kernel Mode verbracht haben. Anzeigen bzw. Ändern der Minimal- und Maximalgröße des Working Sets des Prozesses. 5.4 Erzeugen von Threads Der Prototyp der Funktion CreateThread zum Erzeugen eines Threads lautet: HANDLE CreateThread( LPSECURITY_ATTRIBUTES lpthreadattributes, // pointer to thread security attributes DWORD dwstacksize, // initial thread stack size, in bytes LPTHREAD_START_ROUTINE lpstartaddress, // pointer to thread function LPVOID lpparameter, // argument for new thread DWORD dwcreationflags, // creation flags LPDWORD lpthreadid // pointer to returned thread identifier Als erstes fällt auf, dass im Gegensatz zu CreateProcess der Rückgabewert von CreateThread das Handle für den neuen Thread ist. Der neu erzeugte Thread wird also wiederum ungefragt geöffnet, um Ihnen die Möglichkeit zu geben, den Lieblingsfehler aller Windows-Programmierer zu machen und das Schließen des Handles zu vergessen. Den Parameter lpthreadattributes kennen wir schon von CreateProcess. Chr. Vogt, FH München 19

20 DwStackSize gibt die ursprüngliche Größe des Stacks des neuen Threads an. Wenn 0 angegeben wird, wird der Stack genauso groß angelegt wie der des primären Threads des Prozesses. lpstartaddress ist die Startadresse, an der der neue Thread mit der Ausführung beginnt. Typischerweise ist dies die Adresse einer Funktion, die folgendem Prototyp zu genügen hat: DWORD WINAPI ThreadFunction(LPVOID lpthreadparameter die also einen 32-bit-Zeiger als Argument hat und einen 32-bit-Wert zurückgibt. Der Funktion wird natürlich derjenige Parameter übergeben, der im Parameter lpparameter von CreateThread angegeben wurde. Analog der Funktion WinMain wird auch diese Funktion nicht direkt aufgerufen. Statt dessen ruft das Betriebssystem eine interne Thread-Start-Funktion aus KERNEL32.DLL auf, die die Thread-Funktion aufruft und nach deren Rückkehr den Thread durch Aufruf von ExitThread beendet. Die einzige mögliche Flag für den Parameter dwcreationflags von CreateThread ist CREATE_SUSPENDED. Bei Angabe von 0 für diesen Parameter beginnt der Thread sofort mit der Ausführung. (In Windows XP und 2003 Server wurde eine weitere Flag eingeführt.) Im letzten Parameter, lpthreadid, wird schließlich noch angegeben, wo die Thread-Identification des Threads abgelegt werden soll. Schauen wir uns noch kurz an, welche Schritte das Betriebssystem bei einem Aufruf von CreateThread ausführt: 1. Das Betriebssystem erzeugt ein internes Threadobjekt. Der Rückgabewert von CreateThread ist ein Handle zu diesem Objekt. 2. Das Betriebssystem initialisiert den Exit-Code des Threads mit dem Wert STILL_ACTIVE und setzt den Benutzungszähler des Thread-Objekts auf Das Betriebssystem reserviert eine Struktur vom Typ CONTEXT für den neuen Thread. Diese Struktur enthält die Werte der vom Thread verwendeten CPU-Register zum Zeitpunkt der letzten Unterbrechung des Threads. 4. Das Betriebssystem erzeugt einen eigenen Stack für den neuen Thread. Es reserviert dazu einen entsprechenden Bereich des Prozessadreßraums und ordnet diesem dann (zunächst) zwei physikalische Speicherseiten zu. 5. Die Werte von lpstartadress und lpparameter werden auf dem Stack abgelegt, so dass es so aussieht, als ob dies an die interne Thread-Start-Funktion übergebene Parameter wären. 6. Das Betriebssystem initialisiert das Stackpointer-Register der CONTEXT-Struktur des Threads mit der Adresse der in Schritt 5 auf dem Stack plazierten Werte und weist dem Befehlszähler die Adresse der internen Thread-Start-Funktion zu. 5.5 Beenden von Threads Wie ein Prozess kann auch ein Thread auf dreierlei Arten beendet werden: 1. Der Thread beendet sich selbst durch Aufruf von ExitThread. 2. Ein anderer Thread im selben oder einem anderen Prozess ruft TerminateThread auf. 3. Der Prozess, zu dem der Thread gehört, endet. Chr. Vogt, FH München 20

21 Die Prototypen für ExitThread und TerminateThread lauten: VOID ExitThread( DWORD dwexitcode // exit code for this thread beendet den Thread, der diese Funktion aufruft. Dagegen beendet BOOL TerminateThread( HANDLE hthread, DWORD dwexitcode // handle to the thread // exit code for the thread den durch das Handle angegebenen Thread, der zum selben oder zu einem anderen Prozess gehören kann. Diese Funktion sollte möglichst nicht verwendet werden, da dabei so gut wie keine Aufräumarbeiten in dem zu beendenden Thread durchgeführt werden. So bleibt z.b. dessen Stack allokiert und eine evtl. von ihm benutzte Critical Section wird nicht freigegeben. Beim Beenden eines Threads werden die folgenden Schritte ausgeführt: 1. Alle dem Thread gehörenden Handles zu Fenstern und Hooks (was immer das ist) werden freigegeben. (Alle anderen Handles gehören sowieso nicht dem Thread, sondern dem Prozess!) 2. Das Thread-Objekt geht in den Signalled State. 3. Der Exit-Code des Threads wechselt von STILL_ACTIVE in den Code, der der Funktion ExitThread bzw. TerminateThread übergeben wurde. 4. Falls der betroffene Thread der letzte Thread seines Prozesses ist, wird auch der Prozess beendet. 5. Der interne Benutzungszähler des Thread-Objekts wird um 1 dekrementiert. Das Thread-Objekt und der dafür benötigte Speicher werden noch nicht unbedingt freigegeben sondern erst dann, wenn alle noch existierenden Bezüge auf das Objekt (also Handles anderer Prozesse zu diesem Objekt) geschlossen worden sind. 5.6 Weitere Funktionen für Threads Die folgende Tabelle beschreibt kurz einige weitere wichtige Funktionen beim Umgang mit Threads. Bei Bedarf oder Interesse lesen Sie bitte Einzelheiten in der Dokumentation nach. GetCurrentThread GetCurrentThreadId SuspendThread ResumeThread Sleep Um ein Pseudohandle für den aktuellen Thread zu erhalten. Um die Thread-Identification des aktuellen Threads zu erhalten. Um die Ausführung eines Threads (vorübergehend) anzuhalten bzw. wieder fortzuführen. Unterbrechen der Ausführung des aktuellen Threads für ein bestimmtes Intervall (Angabe in Millisekunden). Chr. Vogt, FH München 21

22 GetThreadPriority SetThreadPriority GetThreadPriorityBoost SetThreadPriorityBoost GetThreadTimes Abfragen bzw. Ändern der (relativen) Priorität eines Threads. Die möglichen Werte sind: THREAD_PRIORITY_IDLE (1 bzw. 16) THREAD_PRIORITY_LOWEST (-2) THREAD_PRIORITY_BELOW_NORMAL (-1) THREAD_PRIORITY_NORMAL THREAD_PRIORITY_ABOVE_NORMAL (+1) THREAD_PRIORITY_HIGHEST (+2) THREAD_PRIORITY_TIME_CRITICAL (15 bzw. 31) Abfragen bzw. Einstellen, ob für einen Thread eine automatische Prioritätenanpassung durch das Betriebssystem gemacht werden soll. Liefert vier Zeitangaben für einen Thread: Den Erzeugungszeitpunkt des Threads. Den Beendigungszeitpunkt des Threads. Die Zeit, die der Thread im User Mode verbracht hat. Die Zeit, die der Thread im Kernel Mode verbracht hat. Chr. Vogt, FH München 22

23 6 Synchronisation In diesem Kapitel betrachten wir die im Kernel von Windows vorgesehenen Methoden für die Synchronisation von Threads. Im ersten Abschnitt werden alle Synchronisationsobjekte des Kernels aufgelistet und die Funktionen behandelt, wie auf diese gewartet werden kann. Im zweiten Abschnitt wird auf eine weitere Synchronisationsmethode eingegangen, die das Win32-API anbietet, die Critical Sections. Diese greifen natürlich letztlich auf eine der Methoden des Kernels zurück. Die weiteren Abschnitte behandeln die Benutzung der Kernel-Objekte, die speziell für die Synchronisation zwischen Threads existieren, nämlich Mutexe, Semaphore, Events und Waitable Timer. Im letzten Abschnitt werden dann noch die API-Funktionen besprochen, die für die atomare Ausführung von Operationen existieren. 6.1 Warten auf Synchronisationsobjekte Von allen Objekttypen des Kernels ist eine Teilmenge als sog. Synchronisationsobjekte implementiert. Ein Synchronisationsobjekt befindet sich zu jedem Zeitpunkt in einem von zwei Zuständen: Signalled State Nonsignalled State Die Bedeutung dieser beiden Zustände ist vom Typ des Objektes abhängig (siehe die untenstehende Tabelle). Die Gemeinsamkeit ist, dass ein Thread mit Hilfe der Wait Services des Objektmanagers darauf warten kann, dass ein Objekt in den Signalled State übergeht. Solange das Objekt im Nonsignalled State ist, ist der Thread blockiert. Sobald das Objekt in den Signalled State übergeht, weckt das Betriebssystem einen oder alle (je nach Typ des Objekts) auf dieses Objekt wartenden Threads auf. Die folgende Tabelle zeigt die Objekttypen, die als Synchronisationsobjekte implementiert sind sowie die Bedeutung des Signalled State für den speziellen Objekttyp und gibt an, ob beim Übergang des Objekts in den Signalled State einer oder alle der wartenden Threads geweckt werden. In der Tabelle nicht aufgeführt ist ein weiteres Synchronisationsobjekt des Kernels, das nur dem Win32-Subsystem zur Verfügung steht: die event pairs. Chr. Vogt, FH München 23