Bedingungsvariable – warum ist der Aufruf von pthread_cond_signal() vor dem Aufruf von pthread_cond_wait() ein logischer Fehler?

Es ist im POSIX-Threads-Tutorial geschrieben
https://computing.llnl.gov/tutorials/pthreads/
dass es sich um einen logischen Fehler handelt.

Meine Frage ist, warum es ein logischer Fehler ist?

In meinem Programm muss ich diese Signale verwenden, aber ich kann nicht garantieren, dass es einen Thread gibt, der sich im Zustand _cond_wait befindet. Ich habe versucht es zu testen und es passiert nichts. Kann dies zu unerwartetem Verhalten oder Schlimmerem führen?

Danke schön!

Die Antwort von blaze kommt dem am nächsten, ist aber nicht ganz eindeutig:
Bedingte Variablen sollten nur verwendet werden, um eine Änderung einer Bedingung zu signalisieren.

Thread 1 prüft eine Bedingung. Wenn die Bedingung nicht erfüllt ist, wartet er auf die Bedingungsvariable, bis die Bedingung erfüllt ist. Da die Bedingung zuerst geprüft wird, sollte es ihm egal sein, ob die Bedingungsvariable signalisiert wurde:

pthread_mutex_lock(&mutex); 
while (!condition)
    pthread_cond_wait(&cond, &mutex); 
pthread_mutex_unlock(&mutex);

Thread 2 ändert die Bedingung und signalisiert die Änderung über die Bedingungsvariable. Es ist ihm egal, ob Threads warten oder nicht:

pthread_mutex_lock(&mutex); 
changeCondition(); 
pthread_mutex_unlock(&mutex); 
pthread_cond_signal(&cond)

Das Endergebnis ist: die Kommunikation erfolgt über eine Bedingung. Eine Bedingungsvariable weckt nur wartende Threads auf, damit sie die Bedingung überprüfen können.

Beispiele für Bedingungen:

• Warteschlange ist nicht leer, daher kann ein Eintrag aus der Warteschlange genommen werden
• Ein boolesches Flag wird gesetzt, sodass der Thread s wartet, bis der andere Thread signalisiert, dass es in Ordnung ist, fortzufahren
• Einige Bits in einem Bitset sind gesetzt, sodass der wartende Thread die entsprechenden Ereignisse verarbeiten kann

siehe auch pthread-Beispiel

Meine 2 Cent: Ich kenne die Nebenwirkungen des Aufrufs von *pthread_cond_signal()* nicht, wenn kein Thread mit dem Aufruf von *pthread_cond_wait()* blockiert wurde. Dies ist wirklich ein Implementierungsdetail. Ich denke, wenn Ihr Threading-/Timing-Modell nicht die richtige Reihenfolge zwischen Warten und Signal garantiert, sollten Sie wahrscheinlich einen anderen Synchronisierungsmechanismus in Betracht ziehen [like a simple semaphore, for example] wenn Sie die Semaphore von Thread B signalisieren können, auch wenn Thread A den Synchronisationspunkt noch nicht erreicht hat. Wenn Thread A den Synchronisationspunkt erreicht, findet er das inkrementierte Semaphor vor und tritt in die kritische Sitzung ein.

Ich schreibe meine Antwort, weil ich nicht die sehe, die die Menschen beruhigen wird. Ich bin auch über diese bizarre, beunruhigende Warnung vor „logischen Fehlern“ in diesem Tutorial gestolpert. Beachten Sie, dass es nichts über diesen „Fehler“ in gibt den POSIX-Dokumentationsartikel auf pthread_cond_signal. Ich bin sicher, dass dies eine unglückliche Wahl des Begriffs oder ein einfacher Fehler des Autors des Tutorials ist. Ihre Behauptung kann so interpretiert werden, als würde ein Prozess in dieser Situation mit einem Fehler enden oder dass jedes Programm, das diese Situation zulässt, falsch ist. Nichts dergleichen ist wahr. Solche Situationen sind üblich. Das sagt die Dokumentation

Der pthread_cond_signal() und pthread_cond_broadcast() Funktionen haben keine Wirkung, wenn derzeit keine Threads blockiert sind cond.

Also mach dir keine Sorgen und sei glücklich.

Eine Bedingungsvariable ermöglicht es einem Thread, einen anderen aus einer Wartezeit aufzuwecken. Sie funktionieren nur, wenn in dem Moment, in dem Sie die Bedingung auslösen, ein Thread wartet. Um sicherzustellen, dass dies der Fall ist, sperrt der wartende Thread einen Mutex, der mit der Bedingung verknüpft ist, und der signalisierende Thread sperrt diesen Mutex, bevor er die Bedingung auslöst. Mit anderen Worten, der signalisierende Thread kann den Mutex nur sperren und die Bedingung auslösen, wenn der andere Thread den Mutex gesperrt hatte, aber jetzt wartet.

Ich bin am vertrautesten mit Boost, also werde ich das in diesem Beispiel verwenden:

// A shared mutex, global in this case.
boost::mutex myMutex;

// Condition variable
boost::condition_variable myCondition;

void threadProc()
{
    // Lock the mutex while the thread is running.
    boost::mutex::scoped_lock guard( myMutex );

    while( true )
    {
        // Do stuff, then...

        myCondition.wait( guard ); // Unlocks the mutex and waits for a notification.
    }
}

void func()
{
    // Function wants to trigger the other thread. Locks the mutex...
    boost::mutex::scoped_lock guard( myMutex );

    // Since the mutex is locked, we know that the other thread is
    // waiting on the condition variable...
    myCondition.notify_all();
}

Eine Bedingungsvariable zu signalisieren, wenn es kein entsprechendes Warten gibt, ist ein logischer Fehler, weil nichts jemals das Signal empfangen wird. Bedingungsvariablen bleiben nicht in einem signalisierten Zustand.

Wenn Sie sich nicht darum kümmern, dass dieses Signal verloren geht, liegt kein Fehler vor. Es ist nur ein Fehler, wenn Sie erwarten, dass ein später kommender wartender Thread sofort von cond_wait() aufwacht.

Da dies ein üblicher Anwendungsfall für pthread_cond ist, ruft das Tutorial diesen logischen Fehler auf. Aber nichts stürzt ab und es tritt kein unerwartetes Verhalten auf. Im normalen Ausführungsablauf kann cond_signal() immer noch ausgegeben werden, wenn es keine Threads in cond_wait() gibt: Beispielsweise führen alle Leser möglicherweise nur eine Nachrichtenverarbeitung durch, wenn der Schreiber ein weiteres Datenstück in die Warteschlange einfügt.