Quote:
Originally Posted by tarunchawla
Each process has its own address space but threads of a same process have same address space.
|
Good start. But I think your description got both less accurate and less understandable after that. I would advise the OP to stop reading your post after that first sentence.
Quote:
...
When we encounters two tasks having some strong relation with each other we put them into one process as threads.
|
I'm having trouble guessing what you might mean by "we encounters". It is especially hard to find a meaning that makes that sentence correct.
From the point of view of selecting one or the other in adding parallelism to an application design, the big difference between threads and processes is that multiple threads within a process share that process's address space.
Two processes can share memory that is mapped into each of their address spaces. So even that big difference is not an absolute design constraint in choosing multiple threads vs. multiple processes.
There is a big overhead to creating, maintaining, and eventually deleting and address space. So having multiple processes has more overhead than multiple threads within a process.
But the design decision between the two usually comes down to shared memory.
With multiple threads in one process, it takes extra programming effort every time you want to not share some memory between threads. For example, there are often static or global variables that would cause conflicts if freely shared and don't really need to be shared at all: Things would be simpler if each thread just had its own copy. It is possible to set up such thread local replacements for static or global variables, but it is significant extra work. Often it is easier to use locking to control sharing even though there is no underlying benefit to having that sharing (vs. private copies).
With multiple processes, memory by default is not shared. Static and global variable are private to each process and you need extra effort everywhere you do want to share memory.