Good use of threads?

Question

I have a set of operations that are very expensive but are all pretty much self-contained. Some of them rely on some "global" states or data, but all very much read-only. The operations themselves, I'm fairly certain, can all be done in parallel, but all the operations need to complete before the program progresses past a certain point.

Is it worth it to add the extra work and danger of multithreading here, especially since the main thread will have to block and wait anyway?

The other issues is that this application will most likely have to run on both Windows and Linux and I'm not sure it's worth the complexity of adding code that uses two different threading systems.

Answer 1

Well, the first question is: do you actually have a problem?

It sounds like you could certainly parallelize this reasonably safely and efficiently, but if it's not actually a problem to wait for the operations to execute in serial, it may not be worth worrying about.

If this is a batch application which executes overnight, for instance, it's probably not worth doing. If, however, this is a user-facing application and users are getting fed up of waiting, it sounds like it would be worth using multi-threading to solve the issue.

Answer 2

Unless your worker threads are some set of pathological cases that get no parallelization benefits, they'll probably complete faster in parallel than serially. So the question of whether it's worth it becomes one of how much time that saves and how much that's worth to you in context. If there's an antsy user waiting for a mouse click to do something, then saving 5 out of 10 seconds is a meaningful benefit. Same savings in a cron job, not so much.

If you think there's a decent chance that it'll do something useful for you, build a quick test version and profile it.