I was asked below two questions in an software engineer interview but could not answer. I did goggle search but could not find answer.
a. When is multi process application is better than multi thread application in a single machine? b. When is multi thread not possible in a single machine but multi process is possible?
CodePudding user response：
Multi-process is better than multi-threaded when you need to isolation that processes provide to prevent tasks from interfering with each other or the controlling process. This can mean, for example:
- You want to be able to terminate tasks abruptly. If they are processes, then the OS will ensure that their system resources are released; or
- You just want to be sure that a task's resources are freed when it completes, even if it completes normally; or
- You have a (non-adversarial) multi-tenant system; or
- You want to be sure that tasks do not inadvertently share memory, etc.
I'm not sure what the asker wants w.r.t. multi-threading being "impossible", but maybe he is thinking of one of the above scenarios, or just when you're using a host environment like NodeJS that doesn't allow multi-threading.
CodePudding user response：
There are a few situations where multiple processes might be better than a single multi-threaded process:
If you want to parallelize some software that wasn't designed to run (well) in multiple threads in a single process. (Two examples would be the Python interpreter whose GIL limits multithreaded performance, and GUI toolkits like Qt that require all GUI widgets to live in a single thread)
If you're worried that the software might crash or corrupt data and want to limit the scope of the damage that occurs if/when that happens. (if one of the threads of a multithreaded program goes awry, it can and usually does affect/corrupt/crash all of the threads in the process; OTOH if a process crashes, the other processes will not be directly affected)
If you want your software to be able to recover from a crash. That's nearly impossible to do in a single-process program, but with multiple processes you can have a parent "babysitter" process that watches for when its children crash or exit and responds by re-launching them when necessary.
If you want to make sure your threads don't spy on each other. (For example, you might have a program being used by multiple unrelated users at once, and you want to make sure that user A's private data can't possibly get "leaked" to user B -- keeping the users' data in separate processes would go a long way towards enforcing that restriction)
If you want your threads/processes to run with different levels of privilege. In a multiprocess model, you can have different processes running as different users with different access levels; whereas in a single multithreaded process, all threads will be running as the same user and therefore have the same privileges/permissions as each other.
As for when a multithreaded process is not possible: the only scenario I can think of is in an (old) OS that doesn't support multi-threaded programs, but does support multiple processes. Many of the more ancient variants of Unix were like that.
CodePudding user response：
Q1. When multi thread is not possible in a single machine but multi process is possible?
A1:
When the operating system kernel does not support native threads and the application's runtime doesn't implement "green threads". (Research the terms "native thread" and "green thread".)
When the application itself is single-threaded. (Research the terms "single-threaded" and "multi-threaded" in the context of application design and implementation.) Applications need to be written to be multi-threaded.
Q2: When is multi process application is better than multi thread application in a single machine?
A2:
When the language's implementation of multi-threading cannot effectively use multiple cores. For example, research the problem of the Global Interpreter Lock (GIL) in some Python implementations.
When the programmer doesn't have the concurrent programming skills needed to develop a multi-threaded program. For example, a typical undergraduate course in Java doesn't go into the level of detail needed to really understand Java concurrent programming.
There are other "whens" that apply in more specific scenarios.
Note that writing a single-threaded application is easier than writing a multi-threaded one, so it may be easier to use multiple processes instead of multiple threads. But that not about what is possible, or even necessarily better. These things are highly context dependent. The depend on the program, the language, the skills of the developer and so on.
And there are definitely scenarios where multi-threading can give a better solution than multiple processes despite all of the above.