Ich habe an mehreren Stellen gelesen, dass Boost.Signals nicht threadsicher ist, aber ich habe nicht viel mehr Details darüber gefunden. Dieses einfache Zitat sagt nicht wirklich viel. Die meisten Anwendungen haben heutzutage Threads - auch wenn sie versuchen, Single-Threading zu sein, können einige ihrer Bibliotheken Threads verwenden (zum Beispiel libsdl).
Ich denke, die Implementierung hat keine Probleme mit anderen Threads, die nicht auf den Slot zugreifen. So ist es zumindest threadsicher in diesem Sinne.
Aber was genau funktioniert und was nicht? Würde es funktionieren, es aus mehreren Threads zu verwenden, solange ich nicht gleichzeitig darauf zugreife? I.e. wenn ich meine eigenen Mutexe um den Schlitz herum baue?
Oder muss ich den Slot nur in dem Thread verwenden, in dem ich ihn erstellt habe? Oder wo ich es zum ersten Mal benutzt habe?
Ich denke auch nicht, dass es zu klar ist, und einer der Rezensenten der Bibliothek sagte hier :
Ich mochte auch nicht, dass nur dreimal das Wort "thread" benannt wurde. Boost.signals2 möchte eine "Thread Safe Signals" -Bibliothek sein. Deshalb noch etwas mehr Details und vor allem weitere Beispiele zu diesem Bereich sollten gegeben werden der Benutzer.
Eine Möglichkeit, dies herauszufinden, ist es, zur Quelle
Von dem, was ich sammeln kann, stellt es einfache Dinge sicher wie "Wenn ein Thread Verbindungen herstellt oder trennt, verursacht das keinen anderen Thread, der durch die mit diesen Signalen verbundenen Slots iteriert". So wie die Verwendung einer threadsicheren Version der C-Laufzeitbibliothek sicherstellt, dass zwei Threads, die gleichzeitig gültige Aufrufe von printf ausführen, keinen Absturz verursachen. (Um nicht zu sagen, dass die Ausgabe, die Sie erhalten werden, Sinn machen wird - Sie sind immer noch verantwortlich für die Semantik höherer Ordnung.)
Es scheint nicht wie Qt zu sein, in dem der Thread, auf dem ein bestimmter Slot-Code ausgeführt wird, auf der "thread affinity" des Ziel-Slots basiert (was bedeutet, dass das Auslösen eines Signals Slots auf vielen verschiedenen Threads auslösen kann) parallel.) Aber ich unterstütze das nicht, deshalb können die boost :: signal "combiners" mache so etwas .
Ein Problem, das ich sehe, ist, dass ein Thread sich verbinden oder trennen kann, während ein anderer Thread signalisiert.
Sie können Ihr Signal ganz einfach umschließen und Anrufe mit Mutex verbinden. Es ist jedoch nicht trivial, die Verbindungen zu umbrechen. (connect gibt Verbindungen zurück, mit denen Sie die Verbindung trennen können).
Tags und Links c++ boost boost-signals