Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as primarily opinion-based by GrandmasterB, MichaelT, gnat, Martijn Pieters, GlenH7 Feb 24 '14 at 14:20

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

The question is, is the application supposed to be able to work in the conditions where you experienced the crash? If it is, you found a bug an need to convince the others of that. If it isn't, then your test is invalid. – Bart van Ingen Schenau Jun 22 '13 at 6:40
@Bart van Ingen Schenau, this is not covered in specs. However, users can run app in bad network conditions, and I believe application must not crash under any conditions. – user626528 Jun 22 '13 at 7:28
any circumstances also includes the PCI bus that stops working or memory chips that break down. But it also does not have to be spelled out in the spec, as long as you can apply some common sense. If it is unspecified what other devices/services are on the same network as your application, then bad network conditions are logically to be expected once in a while. – Bart van Ingen Schenau Jun 22 '13 at 7:34
For the record, I hate questions like this. You know the answer you want. You've told us the answer you want us to give. How we get there is the only detail left unanswered. But what if I think you're wrong? Or, as in this case, "it depends". In many languages you're right. But in both Erlang and Go, it would be fine to have huge numbers of threads, while async would be a bad design. – btilly Jun 22 '13 at 8:37
Gut feelings don't cut it, and I've seen plenty of single-threaded applications that crash with time. What have you done to prove that the crash is actually caused by the presence of so many threads? – Blrfl Jun 22 '13 at 12:05
up vote 8 down vote accepted

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.
share|improve this answer

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.

share|improve this answer
Change better to have more experience. You do not want to antagonize your public :-) – SJuan76 Jun 22 '13 at 8:46
@SJuan76, "have more experience" is enough to antagonize as well ;) – user626528 Jun 24 '13 at 2:38

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.

share|improve this answer

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.

  1. 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?
  2. 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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.