2012-03-26 4 views
1

Ich arbeite an einer Anwendung (c++), die mehrere Arten von Hardware verwendet, um Daten verschiedener Typen gleichzeitig zu sammeln. Das übliche Nutzungsmuster besteht darin, die verschiedenen Schnittstellen zu diesen Geräten (Eye-Tracking, Motion-Tracking, Visualisierung, etc.) jeweils in einem eigenen Thread zu betreiben, so dass sie sich so wenig wie möglich gegenseitig stören. Ich brauche keine Garantie für ein supergenaues Timing, wenn die Threads tatsächlich ausgeführt werden, was, wie ich verstehe, Hardware-Timer erfordern würde. Was ich jedoch erreichen möchte, ist, dass Threads in der Lage sind, einen zentralen Timer irgendeiner Art abzufragen, den sie periodisch verwenden können, um den gesammelten Daten Zeitstempel hinzuzufügen, so dass die Daten (halbgenau) ausgerichtet werden können später zur Analyse. Millisekunden-Genauigkeit ist für diesen Zweck gut.Thread-sicheres Timing zum Ausrichten von Daten, die in mehreren Threads gesammelt wurden - funktioniert QElapsedTimer?

Die Anwendung verwendet Qt für GUI-Zwecke, so dachte ich QElapsedTimer wäre eine mögliche Lösung. Die Dokumente geben jedoch an, dass alle Methoden reentrant nicht Thread-sicher sind. Habe ich Recht, dass dies ein eindeutiges QElapsedTimer Objekt für jeden Thread erfordert, der diese Art von Timing-Funktionalität verwenden möchte? Wenn dies der Fall ist, würde mein Ansatz es erfordern, dass jeder Thread das Timing in einer Blockierungsfunktion (die im Hauptthread ausgeführt wird) initialisiert. Die Initialisierung würde das Erzeugen eines Wrapper-Objekts beinhalten, das einen Timer + einen Versatz von dem "Haupt" -Timer kombiniert, so dass irgendwelche/alle erzeugten Timer mit dem Haupt-Timer "synchronisiert" sind. Dies würde in dem Hauptthread durchgeführt werden, um den Versatz von dem Nicht-threadsafe-Originaltimer zu erhalten.

Ist das ein vernünftiger Ansatz oder gibt es einen besseren "Standard" (Design-Pattern) -Ansatz, den ich stattdessen verwenden sollte? Oder gibt es eine andere Bibliothek, die meinen Zwecken besser entspricht? Momentan arbeite ich an Windows (7 und XP), aber die Anwendung ist möglicherweise plattformübergreifend.

Antwort

2

In Qt haben Sie praktische Klassen wie QMutexLocker für synchrone Aufrufe. Daher können Sie QMutexLocker zusammen mit QMutex verwenden, um die Funktion als threadsicher zu markieren, und dann können Sie QElapsedTimer ohne Probleme über Threads hinweg verwenden.

+0

Danke ... suchte nach einer Möglichkeit, bei jedem Aufruf der Funktion einen Mutex nicht sperren zu müssen, aber es könnte der beste Ansatz sein. Ich implementiere es auf diese Weise für den Moment, ich muss vielleicht zu etwas ähnlich meinem ursprünglichen Vorschlag wechseln, wenn es sich als teurer herausstellt, es auf diese mutexed Weise zu tun. – tmpearce

1

Reentrant bedeutet, dass Sie für jeden Thread mindestens eine andere Instanz benötigen, wenn Sie gleichzeitig darauf zugreifen möchten. Sie können QDateTime auch zum Generieren von Zeitstempeln verwenden, aber das ist auch nicht threadsicher. Ich denke deshalb, es wäre besser, den Zugang zu dieser Methode zu mutexen.