Hintergrund:
Ich habe eine Anwendung, die auf Hardware von Drittanbietern und einen geschlossenen Quelltreiber angewiesen ist. Der Treiber enthält derzeit einen Fehler, der dazu führt, dass das Gerät nach einer zufälligen Zeit nicht mehr reagiert. Dies wird durch einen scheinbaren Deadlock im Treiber verursacht und unterbricht das ordnungsgemäße Funktionieren meiner Anwendung, die sich in einer ständig sichtbaren und rund um die Uhr sichtbaren Umgebung befindet.
Was ich gefunden habe, ist, dass die Verbindung von GDB mit dem Prozess und das sofortige Loslösen von GDB vom Prozess dazu führt, dass das Gerät die Funktionalität wieder aufnimmt. Dies war mein erster Hinweis darauf, dass es innerhalb des Treibers ein Threads Locking-Problem gab. Es gibt eine Art von Race Condition, die zu einem Stillstand führt. Das Anhängen von GDB führte offensichtlich dazu, dass Threads neu gemischt und wahrscheinlich aus ihrem Wartezustand herausgeschoben wurden, was dazu führte, dass sie ihre Bedingungen neu bewerteten und damit den Deadlock lösten.
Die Frage:
Meine Frage lautet einfach: Gibt es eine saubere Wartezeit, bis eine Anwendung alle Threads innerhalb des Programms auslöst, um ihren Wartezustand zu unterbrechen? Eine Sache, die definitiv funktioniert (zumindest bei meiner Implementierung), besteht darin, ein SIGSTOP, gefolgt von einem SIGCONT von einem anderen Prozess (d. H. Von bash), zu senden:
%Vor%Dies löst ein falsches Aufwachen innerhalb des Prozesses aus und alles wird wieder lebendig.
Ich hoffe, dass es eine intelligente Methode gibt, um ein falsches Aufwecken aller Threads in meinem Prozess auszulösen. Denken Sie an pthread_cond_broadcast(...) , aber ohne Zugriff auf die aktuelle Zustandsvariable, auf die gewartet wird.
Ist das möglich, oder verlässt sich auf ein Programm wie kill mein einziger Ansatz?
Die Art und Weise, wie Sie es gerade tun, ist wahrscheinlich die korrekteste und einfachste. Es gibt keine "wake alle wartende futexes in einem bestimmten Prozess" -Operation im Kernel, die Sie benötigen, um dies direkter zu erreichen.
Beachten Sie, dass der Fehler nicht in der Anwendung enthalten sein kann, wenn der Deadlock-Fehler in pthread_cond_wait auftritt, aber mit einem Signal unterbrochen wird, wenn er aus dem Deadlock ausbricht; es muss tatsächlich in der Implementierung von Pthread-Zustandsvariablen sein. glibc hat in seiner Zustandsvariablen-Implementierung nicht behobene Fehler bekannt; siehe Ссылка und zugehörige Fehlerberichte. Sie haben jedoch möglicherweise eine neue gefunden, da ich nicht glaube, dass die bestehenden bekannten durch Ausbrechen der Futex mit einem Signal behoben werden können. Wenn Sie diesen Bug dem glibc bug tracker melden können, wäre das sehr hilfreich.
Tags und Links c multithreading linux posix