2016-05-14 8 views
1

Ich habe derzeit Probleme mit Poco-Threads zum Laden von Wave-Daten, Erzeugen von Wellenformen und Berechnen von Beat-Positionen. Mein Audio-Thread unterscheidet sich von dem, den RTAudio zum Streamen meiner Daten verwendet, daher ist es wichtig, dass Mutex nicht zu lange gesperrt wird, da RTAudio (das meinen Audio-Mutex sperren muss) nicht zu lange warten kann. ..die gerade passiert. Es beginnt jetzt zu passieren, auch wenn das Programm im Leerlauf ist; nicht aufgefordert, etwas zu laden.der Effekt von printf beim Debuggen von Threads

Ich hatte die Idee zu Timing, wie lange Threads blockiert werden, um den Mutex zu bekommen und wie lange sie gesperrt sind, um herauszufinden, wo das Problem ist und es auf der Konsole zu drucken, so würde dies etwa 6 printf sein mit einer Zielframerate von 60 Bildern pro Sekunde.

Ich habe gerade festgestellt, dass, wenn ich auf Konsole zu drucken, der Puffer Unterlauf nicht auftreten, wenn das Programm im Leerlauf ist, sieht es aus wie ein Problem habe ich schlechter mit printf so oft in einem Rahmen gemacht.

Ich würde gerne wissen, wie das passiert, aber was noch wichtiger ist, wie kann ich Thread-Zeiten überwachen, wenn ich printf nicht verwenden kann?

Antwort

1

POSIX erfordert die meisten Standard-E/A-Funktionen, um threadsicher und atomar zu sein. Dies bedeutet, dass mehrere , die im selben Stream arbeiten, sich gegenseitig blockieren. Sie sollten die Dokumentation auf OS-spezifische nicht blockierende Funktionen überprüfen, wenn Sie nicht sperren möchten.

Ähnliche Fragen: stdout thread-safe in C on Linux?