Multithreading or Light-weight processes ?
19 comments
I'm a fan of lightweight processes. I really recommend reading the following:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....
Threads are a seemingly straightforward adaptation of the dominant sequential model of computation to concurrent systems. Languages require little or no syntactic changes to support threads, and operating systems and architectures have evolved to efficiently support them. Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures. In this paper, I argue that this is not a good idea. Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism. Although many research techniques improve the model by offering more effective pruning, I argue that this is approaching the problem backwards. Rather than pruning nondeterminism, we should build from essentially deterministic, composable components. Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed. The consequences of this principle are profound. I argue for the development of concurrent coordination languages based on sound, composable formalisms. I believe that such languages will yield much more reliable, and more concurrent programs.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....
Threads are a seemingly straightforward adaptation of the dominant sequential model of computation to concurrent systems. Languages require little or no syntactic changes to support threads, and operating systems and architectures have evolved to efficiently support them. Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures. In this paper, I argue that this is not a good idea. Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism. Although many research techniques improve the model by offering more effective pruning, I argue that this is approaching the problem backwards. Rather than pruning nondeterminism, we should build from essentially deterministic, composable components. Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed. The consequences of this principle are profound. I argue for the development of concurrent coordination languages based on sound, composable formalisms. I believe that such languages will yield much more reliable, and more concurrent programs.
I second the recommendation of linked paper: It is a very good explanation of why threads are problematic; every programmer who consider using threads ought to read it.
Your definition of "light-weight process" appears to be the same as a normal process.
Indeed. Run
ps -eLf
To see what LWPs are
ps -eLf
To see what LWPs are
Yes, LW-procs are normal processes; but they're written in a way that minimizes resource consumption. I first came across the term while reading about Chrome.
Avoiding terminology like process/thread that varies from system to system; my main point is memory sharing between multiple threads of execution should be avoided.
Avoiding terminology like process/thread that varies from system to system; my main point is memory sharing between multiple threads of execution should be avoided.
The key features are isolation and fault management. Isolation means that each process is separated from the others and can only communicate via a safe means. What happens when a process dies? Good systems have far more fault-tolerance.
An additional benefit is security. Your model can rely on some processes having the capability to access confidential data. These act as proxies for accessing that data and protects it. The OpenBSD operating system has used this "privilege separation" trick for years.
Everything with shared memory will die in the long run. The hardware can't keep on fooling us with a big memory space shared among all processes anyway.
An additional benefit is security. Your model can rely on some processes having the capability to access confidential data. These act as proxies for accessing that data and protects it. The OpenBSD operating system has used this "privilege separation" trick for years.
Everything with shared memory will die in the long run. The hardware can't keep on fooling us with a big memory space shared among all processes anyway.
If you need to process a bitmap in parallel, it's a pain to use processes, since there's a significant amount of memory that has to be passed around. And it's inefficient, as you would always have to copy memory to the other process.
That's what threads are for - parallel paths that need to share memory. Processes are for parallel paths that rarely need to access the same data or to synchronize between them.
Don't forget also that when your CPU shares time, it divides up the time equally among the processes. So if your application creates 20 processes, it takes a disproportionate amount of CPU time (I believe, someone correct me if I'm wrong).
That's what threads are for - parallel paths that need to share memory. Processes are for parallel paths that rarely need to access the same data or to synchronize between them.
Don't forget also that when your CPU shares time, it divides up the time equally among the processes. So if your application creates 20 processes, it takes a disproportionate amount of CPU time (I believe, someone correct me if I'm wrong).
Don't forget also that when your CPU shares time, it divides up the time equally among the processes. So if your application creates 20 processes, it takes a disproportionate amount of CPU time (I believe, someone correct me if I'm wrong).
It depends on the OS. In most cases, threads are the only schedulable entity (think of a classic process as containing one thread), so there is no difference between 20 single-threaded processes and one process with 20 threads.
It depends on the OS. In most cases, threads are the only schedulable entity (think of a classic process as containing one thread), so there is no difference between 20 single-threaded processes and one process with 20 threads.
I don't think this needs to be an "either/or" type of scenario. Depends on the specific requirements.
Sometimes you need a multi-threaded model...i think a GUI library is a good example of that. Other times, a multi-process model would be easier to set up...a "just run in the background" sort of thing.
I also don't quite understand why suddenly everybody is afraid of writing multi-threaded applications. Just make sure you understand how the threading model works in your specific technology and what abstractions are provided. If your application is complex enough to require a "complex algorithm to manage shared memory", then i think you need to really take your time to understand what you're trying to do.
Having said that; I acknowledge that chasing down bugs caused by threads is not fun at all. Especially race conditions since they are seemingly un-predictable. But i think it is getting easier with newer platforms and tools.
Sometimes you need a multi-threaded model...i think a GUI library is a good example of that. Other times, a multi-process model would be easier to set up...a "just run in the background" sort of thing.
I also don't quite understand why suddenly everybody is afraid of writing multi-threaded applications. Just make sure you understand how the threading model works in your specific technology and what abstractions are provided. If your application is complex enough to require a "complex algorithm to manage shared memory", then i think you need to really take your time to understand what you're trying to do.
Having said that; I acknowledge that chasing down bugs caused by threads is not fun at all. Especially race conditions since they are seemingly un-predictable. But i think it is getting easier with newer platforms and tools.
The decision depends on the interactions between them.
Threads make intercommunication cheap but at the price of exposing to problems like deadlocks or data access synchronization overhead.
My rule of thumb is to use process and move to threads only when there is a significant added value.
Threads make intercommunication cheap but at the price of exposing to problems like deadlocks or data access synchronization overhead.
My rule of thumb is to use process and move to threads only when there is a significant added value.
It's a false dichotomy, I think - they're not the only models around. Cf Erlang's process model - no shared memory, and far less resources per process than either OS processes or threads.
Yes, I'm kind of confused about what the original poster is actually talking about. Erlang has a pretty good model, but it's enforced at the language level, not the OS level - strictly speaking, its processes do "share memory" in the sense that they all run in the same OS process. Of course, the implementation more or less prevents them from stomping on one another, so it ends up working quite well.
I don't think lw-process is a good answer to server-side programming. for desktop programming, multi-process can avoid program fails and provide superior performance. but for server-side, considering the consuming of memory and computing resource, threads and lock-free data structure are the better choice. Well, when needing a robust server-side program, you indeed have to program something like lw-process&thread hybrid.
The one that fits the problem at hand is the best model to use. one's not clearly better for all cases than the other.
There is no good answer to this that encompasses all scenarios. Some times it makes more sense to use threads, some times LW procs.
Things like chrome make an interesting case for using LWP in an environment that usually uses threads, but it still does not necessarily mean it is a better solution.
Things like chrome make an interesting case for using LWP in an environment that usually uses threads, but it still does not necessarily mean it is a better solution.
I actually like the competition. I dislike the unconditional fanatics :)
I think we should go back to single-threaded, non-parallel. Those were the days.
"man clone"
Light-weight processes are far more secure than threads in the sense they don't share memory and thus avoid a whole host of problems associated with it.
IMO, they are also easier to work with (while programming); I find the message-passing IPC model simpler and more manageable.
Additionally when it comes to parallel computing; even there light-weight processes are a win-win scenario. There's no need for complex algorithms that manage shared memory between CPUs when each CPU can be assigned 1/more L.W.-processes and they all interact by message passing.
I think on a well designed OS, L.W.-procs should be as efficient as threads.
Some applications like Google Chrome already use L.W.-procs (for each tab the user opens a seperate process is launched). It surprises me that a lot more people don't use it already, given its many advantages.
Which model of multitasking do you think is better? (especially in terms of programmer efficiency)