During my last job interview which was about half year ago, the technical guy asked me, whether the better option is to use e.g. 100 processes to do some work, or only one process but with 100 threads.

There wasn't any information about how many cores the CPU has.

I'm aware that the best answer is...it depends but..

In my opinion the 100 threads solution is (in general) better because:

  • threads shares the same memory

  • there is no necessity to inter process communication

  • creating new thread is cheaper (in resources) than creating process

  • between threads there is possibility to use just pointers

Unfortunately I didn't get any feedback that the answer I gave was right or not.

Ultimately I didn't accept the offer of that company, because...well I got a really better one, but I would like to know, what is the "best" answer of that question.

  • 2
  • 3
    There isn't a right answer, it depends on circumstances which is the better choice. I suspect that the answer they were looking for is "It depends on the circumstances". I also think they were looking for you to explain WHY you'd pick one over the other, that's the bit of the answer that would reveal how much understanding you had of threads vs processes.
    – GordonM
    Commented Nov 28, 2019 at 12:54
  • Search for "context switch": if you have many threads you will get many "context switches" which cost additional CPU time. For single CPU core it should be faster to commute things sequentially, not parallel.
    – neoexpert
    Commented Jul 30, 2021 at 21:17

3 Answers 3


The question is somewhat disconnected from reality but it highlights some interesting engineering topics.

First things first: define the requirements

“Better” must be better defined: is it better robustness or better performance ?

Better robustness ?

The answer should be 100 processes: if any of the process would fail, the others would continue to work.

If you’d go for the threads, a bug on a single thread could corrupt the memory and cause the whole system to fail.

Better performance ?

It depends on the processing capacity, and more precisely the number of CPUs and cores:

In most of the cases the 100 threads will outperform 100 processes, if there are not enough processors.

Why? Because the threads as well as the processes would have to do context switches to share the processor:

  • for threads this is very light, since only registers and some key data/execution structures need to be switched.
  • in comparison, the context switch for processes is much more comprehensive, since you’d also need to ensure memory address space segregation (virtual memory address space swap) , and OS resources (e.g. open files, etc...). So the performance overhead is higher.

Of course, if you have enough processors to compensate this overhead, the 1000 processes could be a choice... unless
they are not completely independent, and need to communicate, which could create a bottleneck in the system, for example due to IPC.

  • Plus with threads you can actually use those overhyped hyper-threading cores.
    – user289860
    Commented Jan 13, 2020 at 13:14

In my opinion the 100 threads solution is (in general) worse because:

  • threads shares the same memory, which means one misbehaving thread can corrupt another thread's memory

  • there is no well-defined inter process communication, threads simply write into each other's memory.

  • creating a new thread is as cheap as creating a new process in well-designed systems (e.g. on the BEAM/HiPE VM, a process uses just ~300 bytes of memory, and it is trivially possible to have 1 million processes even on a not very beefy laptop)

  • between threads there is possibility to use just pointers, meaning that threads can read and write other thread's memory without any form of checking or protection

  • 5
    You are basically saying "it is easier to screw things up using threads if you have no clue of what you are doing so processes are better". This is like claiming spoons are better than knives because with a spoon it is harder to hurt yourself. Communication between threads is as well defined and safe as you want it to be, you just need to apply the features available to you (locking). Commented Nov 28, 2019 at 13:18
  • there is no well-defined inter process communication, threads simply write into each other's memory. But... that's just not true. Sure, at bottom, most (all?) abstractions resort to writing to shared memory, but that doesn't necessitate it being some anarchic wild-west. Depending on the langauge/platform, you have FIFO queues, channels, actor messaging, etc. available to you, for very reliable and well-defined inter-thread communication.
    – Alexander
    Commented Nov 28, 2019 at 16:11

Without any context it is indeed impossible to point out a winner. There are more things to consider than just the technical, performance related questions. Like

  • Location (can the tasks run on the same machine?)
  • Are the tasks depending on each other in terms of execution order or data needs?
  • The responsibilities for the tasks at hand (who is to do or authorize them?)
  • Security issues (accessibility to input and output).

These can all impact your choice. A process is something different than a thread from an organizational point of view. A thread is an execution path within a process so they do not compare well. It is like asking which are better, desktop applications or web applications?

Let's not be too smart over this and focus on performance issues for a moment. Now we still have some questions to answer.

Those 100 execution paths, are they going to be equally busy? It is not uncommon to have a lot of threads in a single process but typically most would be asleep. It is not effective to have them all compete for CPU cycles at the same time so if you have this many threads you want to make sure that no more than some (depending on the number of cores you have to spare) will run at the same time. There are ways to do that. If tasks are basically independent from one another and you just want to do the work as quickly as possible, using threads this way is hard to beat... for a single machine scenario. Because this does not scale well.

Processes can be distributed over an unlimited number of machines, which scales a lot better when just looking at the number of execution paths you could possibly follow simultaneously. But then the question would be where the data is coming from and if there is an issue with distributing input data for those threads. It is impossible to say what the bottleneck is going to be without further context.

So it may have been a smart question with the sole purpose of seeing how strong you are when it comes to getting the information you need to do a good job. You get an unworkable request, what do you do? Will you jump to conclusions and bang away based on assumptions (or without a clue), or will you be a pain in the ass and keep asking until you understand exactly what your client needs? This would tell them something about your understanding of computer science and about whether your personality is up to the challenges typical to their environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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