Sind std::signal und std::raise Thread-sicher?

Question 1

Die C- und C++-Standards unterstützen das Signalkonzept. Der C11-Standard besagt jedoch, dass die Funktion signal() in Multithread-Umgebungen nicht aufgerufen werden kann oder das Verhalten undefiniert ist. Aber ich denke, der Signalmechanismus ist von Natur aus für Multithread-Umgebungen.

Ein Zitat aus dem C11-Standard 7.14.1.1.7

“Die Verwendung dieser Funktion in einem Multithread-Programm führt zu undefiniertem Verhalten. Die Implementierung soll sich so verhalten, als ob keine Bibliotheksfunktion die Signalfunktion aufruft.”

Irgendwelche Erklärungen dazu?

Der folgende Code ist selbsterklärend.

#include <thread>
#include <csignal>

using namespace std;

void SignalHandler(int)
{
    // Which thread context here?
}

void f()
{
    //
    // Running in another thread context.
    //
    raise(SIGINT); // Is this call safe?
}

int main()
{
    //
    // Register the signal handler in main thread context.
    //
    signal(SIGINT, SignalHandler);

    thread(f).join();
}

Question 2

Aber ich denke, der Signalmechanismus ist von Natur aus für Multithread-Umgebungen.

Ich denke, dieser Satz ist das zentrale Missverständnis. signal() ist eine Methode zur Inter-Prozess Kommunikation, nicht für inter-Faden. Threads teilen sich einen gemeinsamen Speicher und können daher über Mutexe und Kontrollstrukturen kommunizieren. Prozesse haben kein gemeinsames Gedächtnis und müssen mit einigen expliziten Kommunikationsstrukturen auskommen, wie z signal() oder das Dateisystem.

Question 3

Ich denke, Sie verwechseln die prozessspezifische Signalisierung mit der Kommunikation zwischen Threads. Wenn Sie Informationen zwischen Threads austauschen möchten, werden Sie wahrscheinlich im neuen finden, was Sie suchen C++11-Thread-Unterstützungsbibliothek. Es kommt natürlich darauf an, was man wirklich machen möchte.

Soweit ich Ihren Code beurteilen kann, möchten Sie, dass ein Thread ein Ereignis auf irgendeine Weise “signalisiert”, und Sie möchten in der Lage sein, Code auszuführen, wenn dieses Ereignis signalisiert wird. Angesichts dessen würde ich mir den Futures-Abschnitt in der Thread-Unterstützungsbibliothek genauer ansehen.

Question 4

Die Aussage des C11-Standards, dass „die Verwendung dieser Funktion in einem Multithread-Programm zu undefiniertem Verhalten führt“, bezieht sich speziell auf die Funktion signal(). Die Frage ist also, ob die Verwendung von signal() erfolgt “in einem Multithread-Programm”.

Soweit ich das beurteilen kann, ist der Begriff „Multithread-Programm“ im C-Standard nicht definiert, aber ich würde damit ein Programm meinen, in dem mehrere Ausführungs-Threads erstellt und noch nicht abgeschlossen wurden. Das würde damals bedeuten signal() in Ihrem Beispielprogramm aufgerufen wird, ist das Programm nicht multithreaded und daher ist das Verhalten des Programms unter dieser Anforderung nicht undefiniert.

(C++11 erfordert jedoch, dass „Alle Signal-Handler eine C-Verknüpfung haben müssen“, [18.10 Other runtime support [support.runtime] S.9]. Da Ihr Beispielprogramm einen Handler mit C++-Verknüpfung verwendet, ist das Verhalten undefiniert.)

Wie andere bereits betont haben, sind Signale nicht für die Kommunikation zwischen Threads gedacht. Zum Beispiel geben die C- und C++-Standards nicht einmal an, auf welchem Thread sie laufen. Die Standardbibliothek bietet stattdessen andere Tools für die Kommunikation zwischen Threads, wie Mutexe, Atomic usw.

Question 5

Ich glaube, Sie interpretieren den Begriff einfach falsch undefiniertes Verhalten, was leider sehr überladen ist mit der Bedeutung “es werden schlimme Dinge passieren”. Hier bedeutet der Begriff wirklich nur, was er sagt: Der C-Standard macht keine Annahmen darüber, was es bedeutet, zu verwenden signal in einem Multithread-Kontext.

Im Allgemeinen die signal/raise interface im C-Standard ist an sich nicht sehr nützlich, sondern nur ein Platzhalter für plattform-/betriebssystemspezifische Dinge, die darüber definiert werden.

Also für eine Interaktion zwischen signal und Drohungen geben dir keinen Vertrag. Oder anders ausgedrückt, das Zusammenspiel von signal und Threads bleibt der Plattformimplementierung überlassen.