I’m working on an application (c++) that utilizes multiple types of hardware to simultaneously collect data of various types. The common usage pattern is to run the different interfaces to these devices (eye-tracking, motion-tracking, visualization, etc.) each in its own thread, so they mess with each other as little as possible. I don’t a need a guarantee of super-precise timing of when the threads actually execute, which I understand would require hardware timers. What I’m looking to do, though, is have threads be able to query a central timer of some kind, which they can use periodically to add time-stamps to the collected data, so the data can be (semi-precisely) aligned later for analysis. Millisecond-scale precision is fine for this purpose.
The application uses Qt for gui purposes, so I thought QElapsedTimer would be a potential solution. However, the docs state that all methods are reentrant, not thread-safe. Am I correct that this necessitates a unique QElapsedTimer object for each thread that wishes to use this type of timing functionality? If this is the case, my approach would be to require each thread to initialize timing in a blocking function (executed in the main thread). Initialization would involve creating a wrapper object which combines a timer + an offset from the “main” timer, so that any/all timers created are “synchronized” to the main timer. This would be done in the main thread in order to obtain the offset from the non-threadsafe original timer.
Is this a reasonable approach, or is there a better “standard” (design-pattern) approach that I should use instead? Or, is there a different library that would better suit my purposes? Currently I’m working on Windows (7 and XP), but the application eventually is slated to be cross-platform.
In Qt you have convenient classes such as QMutexLocker for making synchronous calls. So you can use QMutexLocker along with QMutex in order to mark the function as thread safe, and then you can use QElapsedTimer across threads without any problems.