Thread oder Fiber

« | 18 Dec 2022 | »

Der Aufruf von Sleep() schickt einen Thread schlafen. Aber wenn der Thread ein Fiber ist, wäre es sinnvoller, andere Fibers zu aktivieren, damit die was Sinnvolles tun können.

Doch wie weiß man jetzt, ob man in einem Thread oder in einem Fiber läuft?

---

Vorgeschichte: Crash auf ARM64

Ich schicke Threads selten schlafen, am ehesten warte ich auf Bedingungen mit Events, Conditions oder anderen Objekten. Eine Ausnahme gibt es allerdings: Bei der Ermittlung der aktuellen CPU Auslastung. Denn hierfür soll der aktuelle Thread wirklich “schlafen gehen”, um danach festzustellen, wieviele CPU Aktionen in der Zwischenzeit außerhalb passiert sind.

Tja und heute sehe ich zufällig einen Crash in meiner Sleep-Implementierung:

In dieser wollte ich nämlich genau diese Unterscheidung machen:

• Ist es ein Thread, rufe die OS Sleep() Routine auf.
• Ist es ein Fiber, führe ein yield() aus, damit was anderes abgearbeitet werden kann.

Und für die Unterscheidung nutzte ich einfach GetFiberData() und erwartete einen NULL-Pointer, wenn kein Fiber gestartet wurde.

Das ist leider verdammt falsch!

GetFiberData() ist ein Makro, das GetCurrentFiber() und daraus einen Pointer zum Fiber-Datenpointer ableitet. Dieser wird dereferenziert und genau hier dreht einem der Kernel den Hals um.

GetCurrentFiber() liefert nämlich immer einen Nicht-NULL-Pointer, der aber außerhalb eines Fibers auf “irgendwas” zeigt, nur nicht auf gültige Daten.

Lösung

Windows Vista führte die IsThreadAFiber() Funktion ein, die diese Frage eindeutig klärt. Das heißt, vor einem Get*Fiber*() Aufruf prüft man, ob es sich überhaupt um einen Fiber handelt.

Doch was ist mit Windows XP und älter? Denn hier fehlt diese Schnittstelle.

Meine Lösung ist: IsBadReadPtr(GetCurrentFiber(), sizeof(void*))

Ist dessen Rückgabewert nämlich TRUE laufen wir in einem Thread, ist es FALSE, ist ein Fiber am Werk.

Man könnte natürlich auch per __try/__except/__finally die Dereferenzierung des Pointers gesichert abfangen.

Fazit

Bug fixed.

Hier sieht man wieder mal, wie dumm das ausgehen kann, wenn man einmal Code schreibt, der auf einem anderen aufbaut, und was passiert, wenn man dann 1 Jahr später Koroutinen und Fibers einwebt. Schon ändert sich das Verhalten für einen Fall, den man nicht abgetestet hat.

Mich verwundert, dass IsThreadAFiber() erst 2006 mit Vista eingeführt wurde. Ein solches If-Tool hätte schon im originalen NT 4 1995 drinnen sein müssen.

However … ich habe vorerst einen Workaround und bin glücklich.