Wie löst man ein ungewolltes Aufwecken in einer Linux-Anwendung aus?

Question

Einige Hintergrundinformationen:

Ich habe eine Anwendung, die auf externe Hardware und einen Closed-Source-Treiber 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 offensichtlichen Stillstand im Treiber verursacht und unterbricht die ordnungsgemäße Funktion 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 aus dem Prozess in der Wiederaufnahme der Funktionalität des Geräts resultiert. 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 ist einfach: Gibt es eine saubere Wartezeit für eine Anwendung alle Themen innerhalb des Programms auslösen ihre Wartezustand zu unterbrechen? Eine Sache, die auf jeden Fall funktioniert (zumindest auf meiner Implementierung) ist ein SIGSTOP zu senden, unmittelbar gefolgt von einem SIGCONT aus einem anderen Prozess (dh von bash):

kill -19 `cat /var/run/mypidfile` ; kill -18 `cat /var/run/mypidfile` 

Dies löst eine unechte Weck- innerhalb des Prozesses und alles kommt zurück ins Leben.

Ich hoffe, dass es eine intelligente Methode gibt, um ein ungewolltes Aufwecken aller Threads in meinem Prozess auszulösen. Denken Sie pthread_cond_broadcast(...), aber ohne Zugriff auf die aktuelle Zustandsvariable, auf die gewartet wird.

Ist dies möglich, oder ist ein Programm wie kill mein einziger Ansatz?

Answer 1

Die Art, 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 sein kann, wenn der "Deadlock" in pthread_cond_wait ist, aber die Unterbrechung mit einem Signal 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 http://sourceware.org/bugzilla/show_bug.cgi?id=13165 und zugehörige Fehlerberichte. Vielleicht haben Sie aber 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.