Process Vs Thread

  • 85

    Very common interview question.

    Source of Information:

    0_1496197053309_Screen Shot 2017-05-30 at 7.17.02 PM.png

  • 0

    @revant12 Nice and convinient!

  • 4

    When do we prefer multiple processes over multiple threads?

  • 14

    @feng.wen.503 This isn't a complete answer, but hits on a few key points:

    First, the details are very dependent on the operating system and hardware architecture. That said, these are the typical factors that would determine the decision:

    A process provides

    • Stronger isolation guarantees on operating systems with a protected memory model. That is, incorrect code process A can't directly corrupt memory in process B.
    • Processes also typically have a strong affinity with operating system resources that they consume such that when the process exits, resources can be reclaimed. This includes device resources, memory, and all threads associated with that process.
    • Processes are usually a security boundary in an operating system. For example, a process can be restricted to protect the user from malicious content. As examples, Microsoft Edge uses sandbox processes so that even if an attacker finds a vulnerability in HTML code, they still can't access anything interesting. They need to find a second vulnerability to allow them to escape the sandbox process. A thread cannot provide this type of isolation. Similarly, processes can be used to isolate a more powerful privilege. For example, a process that handles secure data might be designed to have as little code as possible running in it to minimize attack surface.
    • The disadvantage is that a process inherently consumes more resources than a thread, since it must contain at least one thread.

    By contrast, a thread can:

    • Trivially share in-memory data with other threads in the same process (processes can only share memory in specially allocated memory regions created for the purpose).
    • If the system provides a threadpool, the cost of obtaining a thread to do concurrent work can be only little more than the cost of a context switch, making it potentially advantageous to do even small amounts of work in parallel.

  • 2

    @revant12 What do you mean with a thread being a "subset" of the process?

    Btw looks like plagiarized from maybe
    (Edit: revant12 added the link now, originally had pretended that this was their own work. Still violates the copyright, I think, but whatever...)

  • 0

    @benkuhn said in Process Vs Thread:


    what's the different between main thread and process、thread?

  • 0

    @feng.wen.503 when you want to run a piece of code that will be isolated and that won't influence or affect other instances of the program. For example, let's assume you are listening to a socket (and you don't expect a lot of connection) and you don't want to share any information between the connection (for security reasons). In this case, it may be convenient to use a process instead of a thread.

    Obs.: since processes have their own copy of the memory space, you would have to consider another approach to isolate these requests using thread or soft process (like it is done in Erlang/Elixir).

  • 0

    @StefanPochmann You're right its plagiarized.

  • 1

    Thread is not a subset of a process, by no definition I'm aware of. For example, the alpha-numeric characters are a subset of the whole ASCII space. A process, in addition to other characteristics, contains 1 or more threads. This table is by far not the definition of a thread.

    What does "directly communicate with other threads" even mean? maybe "join", but other forms of communication are simply sharing memory (which is described later.

    Threads have almost no overhead? that's just not true.

    I have no idea what the "Changes" section mean. What kind of change? How can these changes can affect other threads? (unless we are talking about memory or resource sharing, like events, queues etc.)

    Process is controlled by the operating system and threads by programmers? what does that mean? what control? definitely not scheduling...

  • 0

    thread is subset of process - not sure what is "set" and "subset" here. A process can be considered as a single thread. A process with more than one threads is possible in which more than one threads shares address space (virtual memory address space) of a process and there can be more than one thread in execution at a time if hardware has more than one cores.

    threads don't share signal masks - at least on Linux. sigprocmask behavior is undefined for multi-threaded process. check pthread_sigmask. So threads do not share signal handling per say - they do share code segment of a process and so functions or handlers are shared.

    Threads have 'almost no overhead' - not sure what do you mean by that. Threads have separate stacks, and register contexts. Also using threads require use of locks or mutices which is "overhead" IMO.

    File system context - not sure what do you mean by file system context but file table is shared even among multiple processes, that is how files are shared. So one file can be open for reading in one process, for writing in second process.

    Processes and threads both can be made either dependent or independent

Log in to reply

Looks like your connection to LeetCode Discuss was lost, please wait while we try to reconnect.