I’m working out (or at least trying to) the schematics on how to split up my app (a development studio for psychology experiments) in multiple threads. Right now, my app does (mainly) the following things :
- poll static events. These are events at a fixed time, so a simple clock-comparision is all that is needed
- poll dynamic events. These are events that are caused by user input such as keypresses, mouseclicks, mouse movement
- poll external equipment (via parallel port or Data Acquisition Cards)
- poll streams (via Data Acquisition cards). These are streams of numbers at 1Khz (buffered by the hardware)
- do some simple calculations on these streams (for instance detect if a stream exceeds a threshold, or calculate the sum of two streams into a new stream)
- draw stuff on the screen (at low speed. Usually there are only 5 to 10 screen updates per ‘trial’, and one program execution has typically 50-100 trials. However, we want these updates to happen EXACTLY when we expect them)
- draw a graph of the active streams on the 2nd monitor
that more or less covers the important parts. Right now, version 4 of the software does all of this without multithreading, which is kind of a shame since all PCs nowadays have multiple cores. So I would like to optimize this. My question is : can you guys give me some tips on what to optimize, and what not ?
for instance, I could split the drawing of the streams from the rest of the app. But is that feasible ? Can one thread draw on one monitor, and another thread on a second monitor ?
Another possibility is to poll equipment on a 2nd thread, an simply set booleans on/off whenever equipment-related events are to be executed… would that be a speed benefit ? Or is the overhead of multithreading greater than the speed gain here ?
any advice would be very welcome !