I’ve stumbled upon this problem when tried to run our application in bad network conditions; it spawns hundreds of threads (which exist long time before termination), and with time the application crashes. However, other developers answered this is “not a bug” and “as designed”.
I have a strong gut feeling that spawning so much threads instead of using async calls is defective design, in the first place. However, my teammates disagree.
Any ideas how I can convince them?
UPD can I say that spawning threads for short running tasks is a bad design? What arguments I can use to support this statement?
10
Spawning a new thread for each task is not necessarily a bad design, but there are some factors that need to be taken into consideration:
- Context switching between threads takes time. If the number of runnable threads becomes very large (an order of magnitude larger than the number of cores/processors you have), then this can negatively affect the perceived performance of the application
- There are only so many threads you can create. If there is no upper limit to the number of threads that an application creates, then the application will run out of resources sooner or later.
- Creating a new thread is a heavy-weight operation. If you create a new thread for every short-running task, you might find that the thread creation takes a significant portion of the time that those threads ‘exist’. Using a work queue and a thread pool might actually increase the performance of the application.
I’m sure you need to explain to them what Thread Pool is. And that each solid framework does have one implemented and people who implemented it are most probably many times better than themselves at solving this kind of problems.
2
Don’t manually manage threads if you don’t have to and instead try to use a thread pool. Pretty much all languages and runtimes that support threads also have a thread pool implementation built into the standard library. So using threads in and of itself is not a bad idea but manually managing threads can get out of hand pretty quickly so in the beginning try to stick with whatever high level thread management comes built-in.
It’s difficult to propose a solution to people who don’t think they have a problem. Your app crashing under certain circumstances is considered acceptable. Like everything there is a level of risk and reward. You can try to approach in one or both directions.
- Will “it was designed that way” be acceptable to users/customers? Personally, I’d suggest the design is flawed (and the designer is an idiot for intentionally doing this) and needs to change because I’ll go find an app that doesn’t crash. Do your collegues want to face these complaints? Maybe it is easier to just fix it?
- Is the fix that difficult? Lots of suggestions give about frameworks that take care of threads for the most part. How difficult would they be to use?
“That’s the way it was designed.” “This is the way we always did it.” If they want to argue that customers don’t care and/or the fix is too difficult to make because of more important features or risk of further hindering the application would sound a lot more like they’ve given this some thought.