Multithreaded application concept

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

You can probably get away with combining 1 & 2, since the slide-show feature is essentially gui oriented anyway.

For #3, you may be able to make do with some kind of asynchronous I/O methodology, so that you don't need to dedicate a polling thread. Not sure if you can do this with USB, but you can certainly get async I/O with serial and network interfaces, so it's worth looking into.

It's probably a good idea to move heavy-weight tasks like 4 & 5 to their own thread. If you aren't doing the analysis and plotting concurrently, maybe one thread for them both. However, you should really consider how much cpu time these activities will need. If the worst-case analyze-and-plot takes much less than half a second, you might even just perform these actions with a call from the gui. Conversely, if there are cases where this will take longer than that, a separate thread is favorable b/c your users won't like a laggy gui.

Just bear in mind that the dark side of threads lies in the inevitable challenge of coordinating them.