Question

I have a small architecture doubt about organizing code in separate functional units (most probably threads?). Application being developed is supposed to be doing the following tasks:

1. Display some images on a screen (i.e. slideshow)
2. Read the data from external device through the USB port
3. Match received data against the corresponding image (stimulus)
4. Do some data analysis
5. Plot the results of data analysis

My thoughts were to organize the application into the following modules:

1. GUI thread (+ image slideshow)
2. USB thread buffering the received data
3. Thread for analyzing/plotting data (main GUI thread should not be blocked while plotting the data which might consume some more time)

So, what do you generally think about this concept? Is there anything else you think that might be a better fit in this particular scenario?

Answer 1

A lot of this depends on how much is involved in performing 3 (Do some data analysis.) and 4 (Plot analyzed data.)

My instincts would be:

Definitely have a separate thread for reading the data off the USB. Assuming for a moment that 3 is dependent on reading the data, then I would do 3 in the same thread as reading the data. This will simplify your signaling to the GUI when the data is ready. This also assumes the processing is quick, and won’t block the USB port (How is that being read? IO completion ports?). If the processing takes time then you need a separate thread.

Likewise if image slide processing show takes a long time, this should be done in a separate thread. If this can be quickly recalculated depending say in a paint function, I would keep it as part of the main GUI.

There is some overhead with context switch of threads, and for each thread added complexity of signaling. So I would only add a thread to solve blocking of the GUI and the USB port. It may be possible to do all of this in just two threads.