Previous | Next --- Slide 9 of 54
Back to Lecture Thumbnails

Also using processes is helpful because usually the requests are independent and it's better to have separate address spaces per process as opposed to shared address space with threads.


I don't really understand what it means to partition into processes. What exactly is meant by a process? Is it just the task that is assigned to a processor? So we're only using 1 execution context on each core to do each process?


@huehue A process is sort of like a thread, in that it is an independent execution of code. You create new threads using pthreadCreate but you create new processes using fork. Threads can share variables between them and live in the same memory space, while processes are completely independent of each other and can't communicate without using some sort of process queue. Threads live inside processes which run instances of code.

Here is a stackoverflow post about threads vs processes.


I believe that threads each have their own stacks but share the heap, while processes have their entirely own memory space (stack, heap, files, etc). So processes to me seem entirely independent of other processes, meaning that a crash in one processor may not affect another, but a crash in one thread would affect another thread sharing the same heap? I'm not too sure about this, just a guess.


As further clarification between threads and processes, is there an equivalent to multithreading with processes, where when one thread stalls, you can switch and perform another thread, or is the fact that processes are completely independent of each other and have their own memory space make switching between processes more expensive and infeasible?


Try to Summarize here, partitioning server into processes means to assign one process per request. The main differences between these two are related to memory usage (theoretically, partitioning into threads can serve more request with bounded memory) and security issues (crashing, thread-safe library mentioned above).

@ote, based on knowledge about OS, we know processes are time-sharing within CPU, thus switching between processes is feasible and more expensive than that between threads.


I will add something more to this discussion with my (limited) OS knowledge:

  • (w.r.t. efficiency) Processes are more heavy-weight than threads. Processes have different virtual address spaces, and thus also different VirtualAddress->PhysicalAddress tables.

  • (w.r.t. security & reliability) Different threads of a process are vulnerable to stack overflow attack since they share the same virtual-address space. On the other hand, the same is near impossible to occur for different processes (since their mapping tables are different). The similar holds for code crashing -- different processes are much more disjoint than different threads.

  • (w.r.t. memory leak) When using processes, a part of memory management is handled by the OS, e.g. when a process is destroyed, any unfreed memory is automatically recycled. If we use multiple threads instead, they need to be careful with freeing memory (since it might be shared across threads).

Conclusion: Overall, worker threads vs worker processes both have pros and cons, and web servers make different design decisions.


I understand why using multiple processes helps prevent a worker crash from bringing down the whole web server, but in this model we're still faced with the problem that the web server going down will cause total failure. By instead using a load balancer that points to multiple web servers, we also prevent a web server crash from taking down the entire site.

That being said, what happens if the load balancer crashes? Are there any ways to prevent the web servers from being unreachable?



In Cloud Computing (15-319) and Distributed Systems (15-440), we call such failure as SPOF (single point of failure). And, building a reliable system is (almost) all about reducing them.

In the real world, multiple load-balancers are used to route traffic to the web servers, and this is usually achieved with some network magics (see an example here:


We should also note, that as might have been observed in assignment 4, the use of processes makes the requests independent. Remember, having separate address space per process is usually much more beneficial than a shared address space with threads.


Just to confirm, our assignment 4 was partitioning the server into threads, right? If we wanna partition it into processes for assignment 4, is there any interface to do that? (maybe the "fork" mentioned by @TomoA can work here?)


@Richard In assignment 4 there were multiple worker process with ideally each having as many thread as number of cores in the machine. We were scaling up and down on the unit of workers(process).


@aarumuga I see... So the process concept was a worker node there.