Scheinwecken — Warum Bedingungsvariablen „ohne Benachrichtigung“ aufwachen und wie Sie unter Windows richtig warten

„Wir legen Daten in die Warteschlange und wecken den wartenden Worker-Thread. Es war sechs Monate gelaufen, dann hat es eines Tages versucht, eine leere Warteschlange zu lesen, und ist abgestürzt.“ „Wir senden die Benachrichtigung, aber ab und zu wacht ein Thread nie auf.“ — Multithread-Rendezvous sieht so aus, als funktionierte es, und ist ein Brutplatz für Fehler, die nur selten erscheinen. Untersuchungen dieser Art landen oft auf Code, der das wait einer Bedingungsvariable in ein if wickelt. Und dahinter sitzt das Scheinwecken (spurious wakeup) — das Phänomen, von wait zurückzukehren, ohne eine Benachrichtigung empfangen zu haben.

„Es wacht auf, obwohl niemand es benachrichtigt hat“ klingt nach einem Defekt der Umsetzung, aber es ist Verhalten, das Win32, C++ und POSIX alle in ihrer Dokumentation oder ihren Standards ausschreiben, und .NETs Monitor ist unter der Annahme entworfen, dass „einmal aufgeweckt, prüfen Sie die Bedingung erneut“. Warum ist dieses Verhalten erlaubt? In welcher Schicht geschieht es unter Windows? Und wie schreiben Sie das Warten, sodass Sie es nie treffen? An Entwickler gerichtet, die Geschäftsanwendungen und Gerätesteuerungssoftware unter Windows schreiben, packt dieser Artikel aus, was ein Scheinwecken wirklich ist, anhand von Primärquellen, und kocht das richtige Warten auf Win32 (C), C++ und C# herunter.

1. Zuerst das Fazit

• Das wait einer Bedingungsvariable kann zurückkehren, auch wenn keine Benachrichtigung angekommen ist. Die offizielle Win32-Dokumentation stellt fest, dass Bedingungsvariablen Scheinwecken (Aufwachen, die nicht an ein ausdrückliches Wecken gebunden sind) und gestohlenen Aufwachen (ein anderer Thread verbraucht die Bedingung, bevor der aufgeweckte Thread es tut) unterliegen.¹
• Also müssen Sie das Warten immer als „eine while-Schleife plus eine erneute Prüfung der Bedingung“ schreiben. Code, der einmal mit if prüft und dann waitet, sieht so aus, als funktionierte er, und beherbergt einen Fehler, der sich nur selten reproduziert.¹²
• Das ist keine Windows-spezifische Eigenheit; POSIX und der C++-Standard sagen dasselbe. Eine Umsetzung, die „absolut nie scheinweckt“, würde jede Bedingungsvariablen-Operation verlangsamen, also ist das Aufwachen unter der Annahme erlaubt, dass der Wartende erneut prüft.³⁴
• In C++ führt die Prädikatform wait(lock, pred) die Schleife durch die Bibliothek für Sie aus. Diese Form führt wirksam while (!pred()) wait(lock); aus. Sie ist die Vorgabe für neuen Code.⁵
• C#s Monitor.Wait braucht dieselbe Disziplin. Die Bedingung kann in dem Intervall zwischen dem Aufgewecktwerden und dem erneuten Erwerben der Sperre verbraucht werden, also prüfen Sie die Bedingung in einem while erneut und gehen zurück zu Wait.⁶
• Aktualisieren und prüfen Sie die Bedingung unter derselben Sperre. Wenn Sie die Bedingung außerhalb der Sperre ansehen und dann wait betreten, kann eine Benachrichtigung durch die Lücke gehen — ein verlorenes Aufwachen.¹
• Bauen Sie die transiente Benachrichtigung einer Bedingungsvariable „wecke, wer gerade wartet“ nicht mit einem Pulse auf einem Ereignis nach. PulseEvent insbesondere kann die Benachrichtigung in dem Augenblick verfehlen, in dem ein Kernelmodus-APC das Warten kurz anhebt, und Microsoft selbst sagt ausdrücklich: „es ist unzuverlässig, nutzen Sie es nicht, nutzen Sie stattdessen eine Bedingungsvariable“.⁷

Was folgt, geht die Mechanismen durch, die diese Schlussfolgerung stützen, der Reihe nach.

2. Was ein Scheinwecken ist — Aufwachen bedeutet nicht, dass die Bedingung gilt

Eine Bedingungsvariable ist ein Synchronisierungsprimitiv zum „einen Thread schlafen legen, bis eine Bedingung gilt, und ihn aufwecken, wenn sie gilt“. Unter Win32 ist das die Struktur CONDITION_VARIABLE zusammen mit SleepConditionVariableCS / SleepConditionVariableSRW (warten) und WakeConditionVariable / WakeAllConditionVariable (benachrichtigen). Die Warte-API gibt atomar die Sperre frei, die Sie halten (eine Critical Section oder eine SRW-Sperre), und geht schlafen, und beim Aufwachen erwirbt sie die Sperre erneut, bevor sie zurückkehrt.¹

Die Frage ist, was die Tatsache, „von wait zurückgekehrt zu sein“, tatsächlich bedeutet. Naiv möchten Sie denken „eine Benachrichtigung ist angekommen = die Bedingung gilt“, aber in Wirklichkeit gibt es drei Fälle, in denen wait zurückkehrt.

flowchart TB
    accTitle: Drei Fälle, in denen wait zurückkehrt
    accDescr: Das Warten einer Bedingungsvariable kann nicht nur von einer echten Benachrichtigung zurückkehren, sondern auch von einem Scheinwecken ohne Benachrichtigung und von einem gestohlenen Aufwachen, bei dem eine Benachrichtigung ankam, die Bedingung aber zuerst verbraucht wurde, sodass jeder Fall die Bedingung erneut prüfen muss
    w["Von wait zurückgekehrt"] --> a["Echte Benachrichtigung"]
    w --> b["Scheinwecken（keine Benachrichtigung）"]
    w --> c["Gestohlenes Aufwachen（Bedingung bereits verbraucht）"]
    a --> r["Die Bedingung erneut prüfen, dann fortfahren"]
    b --> r
    c --> r

Abbildung 1: Es gibt drei Wege zurück von wait, und der Aufrufer kann nicht sagen, welchen er genommen hat, also müssen Sie die Bedingung immer erneut prüfen.

Ein Scheinwecken ist dieser zweite Fall — das Phänomen, dass die Warte-API zurückkehrt, ohne an eine ausdrückliche Benachrichtigung gebunden zu sein, die Sie aufwecken sollte. Es ist nicht auf Situationen beschränkt, in denen WakeConditionVariable nirgendwo im System je aufgerufen wurde. Zum Beispiel kann die Umsetzung unter hoher Last, bei der Benachrichtigungen in einem kurzen Stoß ankommen, zusätzliche wartende Threads in einem Stapel aufwecken, und von der Seite, die keine entsprechende Benachrichtigung hat, ist das ebenfalls ein Scheinwecken. Die Bedingungsvariablen-Seite von Microsoft Learn sagt das deutlich: „Condition variables are subject to spurious wakeups (those not associated with an explicit wake) and stolen wakeups (another thread manages to run before the woken thread). Therefore, you should recheck a predicate (typically in a while loop) after a wait operation returns.“¹

Der wichtige Punkt ist, dass der Aufrufer nicht sagen kann, durch welchen der drei Fälle er zurückgekehrt ist. Wenn Sie es nicht sagen können, gibt es nur eine verfügbare Strategie: jedes Mal, wenn Sie zurückkehren, prüfen Sie die Bedingung selbst, auf die Sie gewartet haben, und gehen Sie wieder schlafen, wenn sie nicht gilt. Das ist der wirkliche Inhalt der eisernen Regel „wickeln Sie wait in ein while“. Andersherum: Solange Sie diese Regel halten, ist der Code korrekt, egal welcher der drei Fälle Sie aufgeweckt hat.

3. Warum die Spezifikation es zulässt — Präzise Benachrichtigung ist teuer

„Aufwachen ohne Benachrichtigtwerden ist doch nur schlampige Umsetzung, oder?“ ist eine faire Frage. Tatsächlich ist es theoretisch möglich, eine Umsetzung zu bauen, die nie scheinweckt. Trotzdem sind POSIX, Windows und der C++-Standard alle auf der Seite „es kann geschehen“ gelandet. Der Grund steht offen in der Rationale für pthread_cond_wait in POSIX (The Open Group Base Specifications).³

Der erste Grund ist Leistung. Zu versuchen, Benachrichtigung, die „zuverlässig genau einen Thread weckt“, streng umzusetzen, fügt besonders auf Multiprozessoren extra Synchronisierungskosten zu jeder Bedingungsvariablen-Operation hinzu. Zwischen Benachrichtigung und Aufwachen sitzt ein Scheduler, und je nach Zeitpunkt von Unterbrechungen und Verdrängung können Sie „einen anderen Thread, der läuft, bevor der, den Sie wecken wollten“ nicht vermeiden. Allen die Kosten zu zahlen, das vollständig abzudichten, ist schlechter, um Bedingungsvariablen schnell zu halten, als hinzunehmen, dass „Sie gelegentlich extra wecken dürfen“.

Der zweite Grund ist die Beobachtung, dass dieser Kompromiss Anwendungen nicht bricht — er macht sie tatsächlich robuster. Weil Scheinwecken erlaubt sind, schreibt korrekter Code immer eine Schleife, die das Prädikat prüft (die Bedingung, auf die gewartet wird). Die POSIX-Rationale sagt, dass das Erzwingen dieser Schleife den Code selbst-dokumentierend und robuster macht.³ Sobald die Schleife da ist, wird die Bedeutung einer Benachrichtigung von „einer Garantie, dass die Bedingung gilt“ zu „einem Hinweis, dass sich die Bedingung geändert haben kann“ herabgestuft, und die wartende Seite wird tolerant gegenüber bescheidenen Entwurfsänderungen auf der Benachrichtigerseite (zu viele wecken, in einem Stapel wecken und so weiter).

Gestohlene Aufwachen sind eine noch strukturellere Sache. Es gibt immer eine Zeitlücke zwischen dem Aufruf von WakeConditionVariable durch den Benachrichtiger und dem erneuten Erwerben der Sperre und der Rückkehr von wait durch den aufgeweckten Thread. Wenn ein dritter Thread die Sperre in diesem Intervall nehmen kann, kann er die Bedingung (den Inhalt der Warteschlange und so weiter) zuerst verbrauchen. Das ist eine Lücke, die keine Politur der Umsetzung tilgen kann, weil sie aus der Form des Werkzeugs Bedingungsvariable selbst kommt.

sequenceDiagram
    accTitle: Zeitachse eines gestohlenen Aufwachens
    accDescr: Der Produzent legt ein Element in die Warteschlange und weckt den wartenden Verbraucher A, aber bevor A die Sperre erneut erwirbt, erwirbt Verbraucher B die Sperre und nimmt das eine Element, sodass die Warteschlange leer ist, wenn A aufwacht
    participant A as Verbraucher A（wartend）
    participant P as Produzent
    participant B as Verbraucher B
    P->>P: Ein Element zur Warteschlange hinzufügen
    P->>A: WakeConditionVariable
    Note over A: Aufgeweckt, wartet auf erneuten Sperrerwerb
    B->>B: Die Sperre erwerben und ein Element nehmen
    A->>A: Die Sperre erneut erwerben und von wait zurückkehren
    Note over A: Warteschlange ist leer（gestohlen）
    A->>A: In der while-Schleife erneut prüfen und wieder warten

Abbildung 2: Ein „gestohlenes Aufwachen“, in dem ein dritter Thread die Bedingung in der Zeitlücke zwischen Benachrichtigung und Aufwachen verbraucht, kann unter jeder Umsetzung geschehen.

Mit anderen Worten: Selbst wenn das Betriebssystem Scheinwecken vollständig ausmerzte, können Sie, solange gestohlene Aufwachen existieren, immer noch nicht „ich bin aufgewacht = die Bedingung gilt“ schreiben. Die erneute Prüfungsschleife des Wartenden ist sowieso nötig, und angesichts dessen ist es billiger, Scheinwecken zuzulassen und die Umsetzung schnell zu halten — das ist das Entwurfsurteil, das Bedingungsvariablen seit Jahrzehnten tragen.

4. In welchen Schichten es unter Windows auftaucht

Diese Eigenschaft zeigt ihr Gesicht, welche Schicht des Windows-Synchronisierungsprimitivs Sie auch nutzen. Um ein Gefühl dafür zu bekommen, dass Sie ihm nicht entkommen, gegen welche Schicht-API Sie auch schreiben, schauen wir uns die repräsentativen Schichten an.

Win32-Bedingungsvariablen (CONDITION_VARIABLE) sind, wie bereits angemerkt, auf SleepConditionVariableCS / SleepConditionVariableSRW als sowohl Scheinwecken als auch gestohlenen Aufwachen unterliegend dokumentiert, und Sie sind verpflichtet, das Prädikat in einer while-Schleife erneut zu prüfen.² Das offizielle Nutzungsbeispiel (eine Produzent-Verbraucher-Warteschlange) schreibt das Warten ebenfalls innerhalb einer while-Schleife.⁸

Das noch tiefer liegende WaitOnAddress ist eine primitivere Warte-API als eine Bedingungsvariable: „warten, bis sich der Wert an einer gegebenen Adresse ändert“ (Windows 8 und später). Selbst diese nahezu unterste Schicht-API hat Dokumentation, die feststellt, „es ist garantiert, zurückzukehren, wenn die Adresse signalisiert wird, aber es ist auch erlaubt, aus anderen Gründen zurückzukehren“, und listet als Beispiele für frühes Aufwachen einen Speicherknappheitszustand, das Aufgeben eines vorherigen Weckens für dieselbe Adresse und das Ausführen eines Checked Builds. Deshalb ist das eigene Nutzungsbeispiel der Dokumentation in der Form „einer while-Schleife, die den Wert erneut vergleicht“.⁹

C++s std::condition_variable ist dasselbe. Die Dokumentation von MSVC sagt von der prädikatlosen wait, dass sie „blockiert, bis durch einen Aufruf von notify_one / notify_all signalisiert. Sie kann auch scheinwecken“, und erklärt, dass die Prädikatform wait(lock, pred) wirksam den folgenden Code ausführt.⁵

while (!Pred())
    wait(Lck);

Mit anderen Worten: Die in C++ empfohlene prädikatförmige wait ist nichts anderes, als dass die Bibliothek Ihnen „wickeln Sie es in ein while“, wie dieser Artikel beschreibt, abnimmt. cppreference stellt ebenfalls fest, dass die prädikatlose wait scheinbar entblockt werden kann.⁴

.NETs Monitor.Wait / Pulse hat seine eigene Warteschlangenstruktur aus einer Wartewarteschlange und einer Bereitschaftswarteschlange, aber die Disziplin ändert sich nicht. Ein durch Pulse / PulseAll aufgeweckter Thread wechselt in die Bereitschaftswarteschlange und kehrt von Wait in der Reihenfolge zurück, in der er die Sperre erneut erwerben kann. Dass ein anderer Thread die Bedingung in dem Intervall vor dem erneuten Erwerben der Sperre verbrauchen kann, ist dasselbe wie unter Win32, und die Dokumentation ist ebenfalls unter der Annahme geschrieben, dass „der aufgeweckte Thread die Bedingung erneut auswertet, die ihn ins Warten hat eintreten lassen, und Wait bei Bedarf erneut aufruft“.⁶¹⁰

flowchart TB
    accTitle: Jede Schicht verlangt, dass das Prädikat erneut geprüft wird
    accDescr: Offizielle Dokumentation verlangt, die Bedingung nach dem Aufwachen in jeder Schicht erneut zu prüfen — C++ std::condition_variable, .NET Monitor, Win32 CONDITION_VARIABLE und das tief liegende WaitOnAddress
    cpp["C++ std::condition_variable"] --> rule["Beim Aufwachen die Bedingung erneut prüfen（while）"]
    net[".NET Monitor.Wait"] --> rule
    win["Win32 CONDITION_VARIABLE"] --> rule
    woa["WaitOnAddress"] --> rule

Abbildung 3: Wechseln Sie die Sprache oder das Framework, und die offizielle Anforderung ist in jeder Schicht des Warteprimitivs immer noch dieselbe: prüfen Sie nach dem Aufwachen erneut.

5. Die richtige Art zu warten — Mit while und einem Prädikat schreiben

Von hier an Umsetzung. Es gibt nur drei Prinzipien.

1. Halten Sie das, worauf Sie warten, als Zustand (ein Prädikat), nicht als „Benachrichtigung“. Die Bedingung ist gemeinsam genutzter Zustand, der durch eine Sperre geschützt ist — „ist die Warteschlange nicht leer?“, „ist das Flag gesetzt?“ —, nicht „wurde ich aufgeweckt?“.
2. Platzieren Sie wait immer innerhalb einer while-Schleife auf der Bedingung. Jedes Mal, wenn Sie aufwachen, prüfen Sie die Bedingung und gehen Sie wieder schlafen, wenn sie nicht gilt.
3. Aktualisieren und prüfen Sie die Bedingung unter derselben Sperre. Der Benachrichtiger aktualisiert den Zustand und benachrichtigt dann.

flowchart TB
    accTitle: Ablauf einer korrekten Warteschleife
    accDescr: Erwerben Sie die Sperre und prüfen Sie die Bedingung; wenn sie nicht gilt, geben Sie die Sperre frei und schlafen Sie; beim Aufwachen erwerben Sie die Sperre erneut und kehren zur Bedingungsprüfung zurück. Fahren Sie mit gehaltener Sperre nur fort, wenn die Bedingung gilt
    l["Die Sperre erwerben"] --> c{"Ist die Bedingung erfüllt?"}
    c -->|"Nein"| s["wait（die Sperre freigeben und schlafen）"]
    s --> wk["Aufwachen（die Sperre erneut erwerben）"]
    wk --> c
    c -->|"Ja"| go["Mit noch gehaltener Sperre fortfahren"]

Abbildung 4: Ein korrektes Warten ist eine Schleife, und es gibt keine Lücke zwischen dem Prüfen der Bedingung und dem Verarbeiten (beides geschieht, während die Sperre gehalten wird).

Diese Form hat einen leicht zu übersehenden Nutzen. In dem Moment, in dem Sie die while-Schleife verlassen, ist festgestellt, während Sie die Sperre noch halten, dass „die Bedingung gilt“. Die Schleife, die gegen Scheinwecken verteidigt, ist so, wie sie ist, eine Garantie, dass es keine Race-Condition-Lücke zwischen dem Prüfen der Bedingung und dem Verarbeiten gibt.

Die Grundform in Win32 (C)

CRITICAL_SECTION cs;
CONDITION_VARIABLE cv;
int queueCount = 0;   // shared state protected by cs

// Initialise once at startup (for static initialisation, cv = CONDITION_VARIABLE_INIT)
InitializeCriticalSection(&cs);
InitializeConditionVariable(&cv);

// Waiter (consumer)
EnterCriticalSection(&cs);
while (queueCount == 0) {                       // always while, never if
    SleepConditionVariableCS(&cv, &cs, INFINITE);
}
// Here the lock is held and queueCount > 0 is guaranteed
--queueCount;
LeaveCriticalSection(&cs);

// Notifier (producer)
EnterCriticalSection(&cs);
++queueCount;                                    // update the state under the lock
LeaveCriticalSection(&cs);
WakeConditionVariable(&cv);                      // notifying after releasing the lock is fine

Sie können die Benachrichtigung (WakeConditionVariable) von innerhalb der Sperre oder von außerhalb aufrufen, aber die Dokumentation sagt, dass das Wecken nach dem Freigeben der Sperre gewöhnlich besser ist, um Kontextwechsel zu reduzieren.¹ Andererseits muss die Zustandsaktualisierung selbst (++queueCount) immer unter der Sperre geschehen. Verwechseln Sie die zwei nicht.

Die Grundform in C++ — Machen Sie Prädikat-wait zur Vorgabe

std::mutex m;
std::condition_variable cv;
std::queue<Item> q;

// Waiter
std::unique_lock<std::mutex> lk(m);
cv.wait(lk, [&] { return !q.empty(); });   // internally while(!pred) wait
Item item = std::move(q.front());
q.pop();
lk.unlock();

// Notifier
{
    std::lock_guard<std::mutex> lk(m);
    q.push(std::move(item));
}
cv.notify_one();

Weil die prädikatförmige wait die Schleife für Sie ausführt, ist ein handgeschriebenes while unnötig. Wenn Sie bestehenden Code reparieren, der noch eine handgeschriebene Schleife hat, ist while (q.empty()) cv.wait(lk); eine korrekte Form, also besteht keine Notwendigkeit, es eilig umzuschreiben. Die einzige inkorrekte Form ist if (q.empty()) cv.wait(lk);.

Die Grundform in C#

private readonly object _gate = new();
private readonly Queue<Item> _queue = new();

// Waiter
lock (_gate)
{
    while (_queue.Count == 0)          // always while, never if
    {
        Monitor.Wait(_gate);
    }
    var item = _queue.Dequeue();
}

// Notifier
lock (_gate)
{
    _queue.Enqueue(item);
    Monitor.Pulse(_gate);              // Monitor.Pulse can only be called inside the lock
}

Monitor.Wait / Pulse / PulseAll können nur von innerhalb einer Sperre (lock-Block) aufgerufen werden, was sich von Win32 unterscheidet. Sie außerhalb der Sperre aufzurufen wirft SynchronizationLockException.¹⁰

Warten mit einem Timeout — Verbleibende Zeit von einer Frist berechnen

Wenn Sie mit einem Timeout warten, dehnt das Übergeben „desselben Timeout-Werts“ bei jeder Schleifeniteration das Warten jedes Mal, wenn ein Scheinwecken geschieht. Die korrekte Form ist, die Frist zuerst festzulegen und die verbleibende Zeit neu zu berechnen.

ULONGLONG deadline = GetTickCount64() + timeoutMs;
EnterCriticalSection(&cs);
while (queueCount == 0) {
    ULONGLONG now = GetTickCount64();
    if (now >= deadline) {
        break;                          // timeout (condition still unsatisfied)
    }
    if (!SleepConditionVariableCS(&cv, &cs, (DWORD)(deadline - now)) &&
        GetLastError() != ERROR_TIMEOUT) {
        break;                          // on failure other than timeout, stop waiting and leave
    }
    // Confirm ERROR_TIMEOUT finally via the while condition and the deadline check
}
BOOL ready = (queueCount > 0);
if (ready) { --queueCount; }
LeaveCriticalSection(&cs);

flowchart TB
    accTitle: Korrekter Ablauf eines Wartens mit Timeout
    accDescr: Legen Sie die Frist zuerst fest, und jedes Mal, wenn Sie aufwachen, prüfen Sie die Bedingung und die Frist; wenn noch Zeit ist, berechnen Sie die verbleibende Zeit neu und kehren zum Warten zurück
    d["Die Frist festlegen"] --> c{"Ist die Bedingung erfüllt?"}
    c -->|"Ja"| go["Zur Verarbeitung fortfahren"]
    c -->|"Nein"| t{"Ist die Frist verstrichen?"}
    t -->|"Ja"| to["Das Timeout behandeln"]
    t -->|"Nein"| w["Verbleibende Zeit berechnen und warten"]
    w --> c

Abbildung 5: Ein Warten mit Timeout übergibt nicht erneut „dieselbe Wartedauer“; es berechnet die verbleibende Zeit von einer Frist neu.

In C++ können Sie diese Berechnung, Frist und alles, der Überladung wait_until (absolute Zeit) plus Prädikat überlassen. Selbst wenn sie bei Timeout zurückkehrt, gibt sie Ihnen den Endwert des Prädikats, sodass Sie auch „sind wir abgelaufen, oder haben wir es geschafft?“ am Prädikat entscheiden können.⁵

6. Ein Katalog der Muster, die Sie vermeiden sollten

Nur einmal mit if prüfen. Das ist der Star des Artikels. In dem Moment, in dem ein Scheinwecken oder ein gestohlenes Aufwachen geschieht, setzt die Verarbeitung mit unerfüllter Bedingung fort. Aus einer leeren Warteschlange nehmen, uninitialisierte Daten anfassen, ein Double Free — das Symptom wird zu „einem Absturz oder einer Datenverderbnis, die nur gelegentlich erscheint“.

Die Bedingung außerhalb der Sperre prüfen oder aktualisieren. Wenn der Wartende die Bedingung außerhalb der Sperre ansieht, entscheidet „noch nicht“ und in der Lücke vor dem Betreten von wait der Benachrichtiger den Zustand aktualisiert und eine Benachrichtigung sendet, wird die Benachrichtigung an eine Bedingungsvariable ohne Wartenden gefeuert und verschwindet. Der Wartende betritt dann wait und wartet weiter auf eine Benachrichtigung, die nie wieder kommt. Das ist ein verlorenes Aufwachen, das Spiegelbild eines Scheinweckens. Der Grund, warum die Warte-API einer Bedingungsvariable so entworfen ist, „atomar die Sperre freizugeben und schlafen zu gehen“, ist genau, diese Lücke zu schließen.¹ Es geschieht nicht, solange Sie Sperrdisziplin halten.

sequenceDiagram
    accTitle: Zeitachse eines verlorenen Aufwachens
    accDescr: Wenn der Wartende die Bedingung außerhalb der Sperre prüft und der Benachrichtiger den Zustand aktualisiert und in der Lücke vor dem Betreten von wait benachrichtigt, wird die Benachrichtigung an eine Bedingungsvariable ohne Wartenden gesendet und verschwindet, und der Wartende wartet weiter auf eine Benachrichtigung, die nie kommt
    participant W as Wartender
    participant N as Benachrichtiger
    W->>W: Die Bedingung außerhalb der Sperre prüfen（unerfüllt）
    N->>N: Den Zustand aktualisieren und benachrichtigen
    Note over N: In diesem Moment kein Wartender
    W->>W: wait betreten
    Note over W: Die Benachrichtigung ist bereits weg und es wacht nie auf

Abbildung 6: Wenn Sie die Bedingung außerhalb der Sperre prüfen, rutscht die Benachrichtigung durch die Lücke zwischen Prüfung und wait — ein „verlorenes Aufwachen“.

Die „transiente Benachrichtigung“ einer Bedingungsvariable mit einem Pulse auf einem Ereignis nachbauen. Ereignisse selbst (CreateEvent + SetEvent) sind kein Anti-Muster. Ein Wecksignal in einem Aufbau, in dem ein einzelner Verbraucher die Warteschlange verarbeitet, bis sie leer ist, oder eine Stoppanweisung, die einmal erhoben nie gesenkt wird (ein Manual-Reset-Ereignis), sind korrekte Nutzungen eines Ereignisses; und wenn Sie es über WaitForMultipleObjects mit anderen Wartezielen verbinden oder eine Prozessgrenze überschreiten wollen, ist eine Bedingungsvariable — ein Benutzermodusobjekt, das nicht über Prozesse hinweg geteilt werden kann — die, die nicht genutzt werden kann.¹ Was gefährlich ist, ist zu versuchen, mit Ereignisoperationen die transiente Benachrichtigung einer Bedingungsvariable nachzubauen, die „nur die Threads weckt, die in diesem Augenblick warten, und keinen Zustand hinterlässt“. Diese Idee führt fast immer zum nächsten Punkt, PulseEvent.

PulseEvent nutzen. Es ist eine API, die auf einem Manual-Reset-Ereignis „jeden derzeit Wartenden weckt und das Ereignis sofort in den nicht signalisierten Zustand zurücksetzt“, aber Microsoft selbst stellt in der Dokumentation fest, dass „diese Funktion unzuverlässig ist und nicht genutzt werden sollte. Sie existiert hauptsächlich für Abwärtskompatibilität. Nutzen Sie stattdessen eine Bedingungsvariable.“ Der Grund ist, dass ein wartender Thread vorübergehend durch einen Kernelmodus-APC aus dem Wartezustand genommen werden und nach Abschluss des APC zum Warten zurückkehren kann. Wenn PulseEvent in diesem kurzen Intervall aufgerufen wird, ist dieser Thread nicht unter „denen, die im Moment des Aufrufs warteten“ enthalten und wird nicht aufgeweckt.⁷ Kernel-APCs sind etwas, das das Betriebssystem intern nutzt; die App kann sie nicht steuern.¹¹ Dieses Problem ist auch eine statische Analysewarnung (C28648).¹² Wenn ein Scheinwecken das Problem von „extra wecken“ ist, ist dies das Problem von „verschlafen, wenn Sie hätten aufwachen sollen“, und eine while-Schleife kann Sie nicht retten — weil die Benachrichtigung selbst verloren ist.

Nur die Benachrichtigung zuerst senden, ohne die Sperre zu halten, bevor der Zustand aktualisiert wird. WakeConditionVariable aufzurufen, während der Zustand noch veraltet ist, und erst dann die Sperre zu nehmen und den Zustand zu aktualisieren — in dieser Reihenfolge sieht der aufgeweckte Thread die Bedingung beim Prüfen immer noch unerfüllt und geht wieder schlafen. Wenn keine weitere Benachrichtigung kommt, bleibt er dort. Beachten Sie, dass, wenn Sie „benachrichtigen → aktualisieren → freigeben“ schreiben, während Sie dieselbe Sperre noch halten, kein echter Schaden entsteht, weil der Wartende die Bedingung nicht prüfen kann, bis er die Sperre erneut erwirbt. Trotzdem, damit Leser diese Sicherheitsbedingung nicht jedes Mal prüfen müssen, ist es sicherer, sich auf die Reihenfolge „den Zustand unter der Sperre aktualisieren und danach benachrichtigen“ zu standardisieren.

7. Wie Sie untersuchen, wenn Sie darauf stoßen

Fehler, die Scheinwecken einbeziehen, sind durch „nur selten erscheinen“ gekennzeichnet. Vom Symptom rückwärts arbeitend teilen sie sich in die folgenden zwei Familien.

Familie 1: Die Verarbeitung setzt mit unerfüllter Bedingung fort. Eine Ausnahme oder ein Absturz durch das Nehmen aus einer leeren Warteschlange, fehlende Ergebnisse und so weiter. Verdächtigen Sie ein Warten ohne Prädikat. Sie können das in der Codeprüfung mechanisch auskämmen — suchen Sie nach Stellen, an denen cv.wait( nur ein Argument hat, und Stellen, an denen SleepConditionVariableCS / Monitor.Wait in if statt in while gewickelt ist. Diese Prüfung erfordert nicht, auf eine Reproduktion zu warten, und ist der Hebel mit dem höchsten Nutzen, den Sie haben.

Familie 2: Ein Thread, der aufwachen sollte, tut es nicht (ein Hänger). Verdächtigen Sie ein verlorenes Aufwachen (die Bedingung außerhalb der Sperre prüfen oder außerhalb der Sperre benachrichtigen, bevor der Zustand aktualisiert wird) und PulseEvent. Nehmen Sie einen Dump vom hängenden Prozess und schauen Sie auf den Stack jedes Threads, und Sie können identifizieren, welcher Thread in welcher Warte-API steckt. Von dort aus verfolgen Sie durch den Code „wer sollte diese Benachrichtigung senden, und in welcher Reihenfolge“.

flowchart TB
    accTitle: Triage-Ablauf vom Symptom
    accDescr: Wenn die Verarbeitung mit unerfüllter Bedingung fortsetzt, kämmen Sie Warten ohne Prädikat durch Durchsuchen des Codes aus; wenn ein Thread nicht aufwacht, identifizieren Sie die Wartestelle aus einem Dump und verdächtigen Sie ein verlorenes Aufwachen oder PulseEvent
    s["Ein Fehler, der nur selten erscheint"] --> a["Verarbeitung setzt mit unerfüllter Bedingung fort"]
    s --> b["Ein Thread, der aufwachen sollte, tut es nicht"]
    a --> a1["Den Code nach Warten ohne Prädikat durchsuchen"]
    b --> b1["Wartende Threads aus einem Dump identifizieren"]
    a1 -.-> a2["if in while ändern oder Prädikat-wait nutzen"]
    b1 -.-> b2["Ein verlorenes Aufwachen oder PulseEvent verdächtigen"]

Abbildung 7: Ob das Symptom „zu weit fortfahren“ oder „nie aufwachen“ ist, teilt sowohl, was Sie verdächtigen, als auch, wie Sie untersuchen.

Wenn Sie es reproduzieren wollen, ist der Standardzug, das Race-Fenster zu erweitern. Erhöhen Sie Timing-Jitter, indem Sie mehr Threads als physische Kerne nutzen, ein absichtliches Sleep zwischen Warten und Benachrichtigen einfügen und sowohl Debug- als auch Release-Builds ausführen. Wenn Sie bestätigen, dass „es aufgehört hat, sich zu reproduzieren, nachdem wir das prädikatlose Warten repariert haben“, vergleichen Sie unter demselben Stress.

8. Zusammenfassung — Eine Checkliste

• Die Wege zurück von wait sind drei — echte Benachrichtigung, Scheinwecken und gestohlenes Aufwachen — und der Aufrufer kann sie nicht unterscheiden. Also schreiben Sie das Warten immer als while-Schleife auf der Bedingung.
• Ein Scheinwecken ist Verhalten, das Win32, C++ und POSIX bewusst als Kompromiss gegen Leistung zugelassen haben, und es wird mit einer Betriebssystemkorrektur oder einem Bibliothekstausch nicht weggehen. .NETs Monitor.Wait wird nicht als grundlos aufwachend angenommen, aber weil gestohlene Aufwachen und Timeouts existieren, ist dieselbe while-Disziplin trotzdem nötig.
• In C++ nutzen Sie standardmäßig die Prädikatform wait(lock, pred). Die Bibliothek führt die Schleife aus.
• Aktualisieren und prüfen Sie die Bedingung unter derselben Sperre. Senden Sie die Benachrichtigung „nach dem Aktualisieren des Zustands“. Win32/C++-Benachrichtigung darf nach dem Freigeben der Sperre geschehen; C#s Pulse ist nur innerhalb der Sperre.
• Für ein Warten mit Timeout legen Sie eine Frist fest und berechnen Sie die verbleibende Zeit neu. In C++ wait_until plus ein Prädikat.
• Bauen Sie die transiente Benachrichtigung einer Bedingungsvariable nicht mit einem Pulse auf einem Ereignis nach. PulseEvent insbesondere ist etwas, von dem offizielle Dokumentation ausdrücklich feststellt: „nutzen Sie es nicht, nutzen Sie stattdessen eine Bedingungsvariable“. Ereignisse selbst bleiben das richtige Werkzeug für eine Stoppanweisung, das Verbinden mit WaitForMultipleObjects und prozessübergreifende Synchronisierung.
• In der Prüfung suchen Sie mechanisch nach „prädikatlosem Warten“ und „if + wait“. Sie können einen selten reproduzierbaren Fehler töten, ohne auf eine Reproduktion zu warten.

Ein Scheinwecken verdichtet sich, entgegen der Seltsamkeit des Namens, auf ein Einzeilen-Stichwort für die Reparatur — ändern Sie if in while. Und hinter dieser einen Zeile liegt die Entwurfsidee des Werkzeugs Bedingungsvariable: „präzise Benachrichtigung ist teuer, also ist das Prüfen die Verantwortung des Wartenden“. Verstehen Sie es als Mechanismus, und Sie sollten dieselbe Disziplin ohne Zögern anwenden können, wenn sich die Sprache oder das Framework ändert.

Weiterführende Artikel

• Praktische Multithreading-Best-Practices: C++-Edition — Unfälle mit RAII und jthread strukturell beseitigen
• Praktische Multithreading-Best-Practices: C-Edition — Sicher schreiben nach Win32-API-Konvention
• Praktische Best Practices für Multithreading: .NET-Edition — Was Sie entscheiden sollten, bevor Sie weitere Threads hinzufügen
• Warum Sie unter Windows Ereigniswarten gegenüber Sleep(1) bevorzugen sollten
• Fallstricke bei Shared Memory und Best Practices für die Praxis
• Die Tiefen von Windows I/O (Teil 2) — Synchrones und asynchrones I/O: Was OVERLAPPED wirklich bedeutet

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt Multithread-Entwurfsreviews, Ursachenuntersuchung (Dump-Analyse) von Abstürzen und Hängern, die „sich nur gelegentlich reproduzieren“, sowie die Migration von Legacy-Synchronisierungscode (ereignis- und PulseEvent-abhängig und Ähnliches) auf eine Bedingungsvariablen-Basis. Vom Triagieren des Symptoms zu beginnen ist in Ordnung — bitte zögern Sie nicht, uns zu erreichen.

• Technische Beratung und Design-Review
• Fehleruntersuchung und Ursachenanalyse
• Windows-Anwendungsentwicklung
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ist ein Scheinwecken ein Fehler im Betriebssystem oder in der Bibliothek?

Nein — es ist Verhalten, das in der Spezifikation ausgeschrieben ist. Win32s SleepConditionVariableCS, C++s std::condition_variable und POSIXs pthread_cond_wait haben alle offizielle Dokumentation oder einen Standard, der ausdrücklich feststellt, dass ein Aufwachen, das nicht an eine Benachrichtigung gebunden ist, auftreten kann. Eine Umsetzung, die es verböte, ist theoretisch möglich, aber sie würde jede Bedingungsvariablen-Operation verlangsamen (besonders die Benachrichtigung auf Multiprozessoren), also ist der Kompromiss, es zuzulassen unter dem Verständnis, dass „die Korrektheit erhalten bleibt, wenn der Wartende die Bedingung erneut prüft“. Das Heilmittel ist daher nicht, auf eine Betriebssystemkorrektur zu warten, sondern wait immer innerhalb einer while-Schleife zu schreiben (oder eine prädikatförmige wait zu nutzen).

Schadet das Einwickeln von wait in eine while-Schleife der Leistung?

In der Praxis sind die Kosten vernachlässigbar. Alles, was die while-Schleife hinzufügt, ist eine zusätzliche Bedingungsprüfung jedes Mal, wenn Sie aufwachen, und das ist ein billiger Vergleich, während Sie die Sperre bereits halten. Scheinwecken selbst sind selten, also geschieht die zusätzliche Schleifeniteration nur in Ausnahmefällen. Die Kosten, die Prüfung als if zu lassen, sind dagegen ein „Fehler, der sich nur selten reproduziert“, in dem die Verarbeitung mit unerfüllter Bedingung fortsetzt — da gibt es keinen Vergleich. Was die Wartekosten einer Bedingungsvariable tatsächlich beherrscht, ist Sperrkonkurrenz und wie oft Sie benachrichtigen, nicht ob das while da ist.

Kann ich Scheinwecken vergessen, wenn ich die prädikatförmige wait von C++ nutze?

Für die Warteschleife ja: cv.wait(lock, pred) ist wirksam while (!pred()) wait(lock);, sodass sowohl Scheinwecken als auch gestohlene Aufwachen automatisch aufgenommen werden. Neuer C++-Code sollte standardmäßig die Prädikatüberladung nutzen. Sie müssen Aktualisierungen des gemeinsam genutzten Zustands, den das Prädikat liest, trotzdem mit demselben Mutex schützen, und der Benachrichtigende muss diesen Zustand trotzdem aktualisieren, bevor er notify aufruft. Prädikat-wait nimmt Ihnen die Schleife ab; es nimmt Ihnen die Sperrdisziplin nicht ab.

Geschieht dasselbe Problem mit C#s Monitor.Wait?

Ja. Ein Thread, der in Monitor.Wait wartet, wird durch Pulse/PulseAll aufgeweckt und erwirbt dann die Sperre erneut, bevor er von Wait zurückkehrt, aber in diesem Intervall kann ein anderer Thread die Sperre zuerst erworben und die Bedingung verbraucht haben (ein gestohlenes Aufwachen). Die Dokumentation von Microsoft ist unter der Annahme geschrieben, dass der aufgeweckte Thread die Bedingung, die ihn warten ließ, erneut auswertet und Wait bei Bedarf erneut aufruft. Also ist die Grundform in C# ebenfalls while (!condition) Monitor.Wait(gate);. Eine Einschränkung, die sich von Win32 unterscheidet, ist, dass Sie Wait/Pulse nur von innerhalb einer lock-Anweisung aufrufen können.

Geschieht Scheinwecken auch, wenn Sie mit WaitForSingleObject auf ein Ereignis warten?

Bei einem gewöhnlichen (nicht alertable) Warten wird WAIT_OBJECT_0 nur zurückgegeben, wenn das Objekt tatsächlich signalisiert wird; es gibt kein „grundloses Aufwachen“ der Art, die Bedingungsvariablen haben. Allerdings sind „das Ereignis wurde signalisiert“ und „die Bedingung Ihrer Anwendung gilt“ verschiedene Dinge. Wenn mehrere Verbraucher durch dasselbe Ereignis aufgeweckt werden, verbraucht der Thread, der die Sperre zuerst nimmt, die Bedingung, also müssen Sie die Bedingung nach dem Aufwachen trotzdem erneut prüfen. Entwürfe, die versuchen, die transiente Benachrichtigung einer Bedingungsvariable „wecke nur, wer in diesem Augenblick wartet“ mit einem Ereignis nachzubauen, stoßen außerdem oft auf das Zuverlässigkeitsproblem von PulseEvent, also ist für das Warten auf eine Bedingung innerhalb eines Prozesses eine Bedingungsvariable das sicherere Werkzeug.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.