Sometime ago i was working on a development project with a small team of developers and was tasked with the responsibility of coming up with a concurrency architecture for the entire solution. At first i was not sure weather to base my concurrency model on threads or on processes and after much tinkering for about a day or so i finally decided to go with processes. Some of the other developers on the team wondered why i decided to go with processes their argument was that process creation and communication was resource intensive and slow compared to threads which is true but i still tend to favor a process-based concurrency model over a thread-based model for the following reasons:

1. Fault-tolerance and scalability is the main advantages of using processes vs. threads.

2. A system that relies on shared memory or some other kind of technology only available when using threads, will be useless you want to run the system on multiple machines. Sooner or later you need to communicate between different processes.

3. Another advantage of processes is that they can crash and you are perfectly ok with that, because you just restart them (even across network hosts). If thread crashes, it may crash the entire process, which may bring down your entire application.

4.Thread-based concurrency models tend to be buggy and difficult to implement correctly.

It depends on what system you are building. You made a reasonable point... But I really do not approve your excuses for your adoption of Interprocess Communication(IPC).
You know quite well that context switching can be expensive. Those crash safety issues you raised arent good excuses. Remember Defensive programming and persistent objects?? For scalability reasons, If you have multiprocessing in mind, you would definitely have to localize most of your routines, still needing threads to do that... Running a remote process wouldnt speed up your app without having most routines atomic and local. I know this cause... Theres a project am working on, dynamically processing a file between two entirely different opensource software, in GTK and WxWidgets....

WhiZTiM: It depends on what system you are building. You made a reasonable point... But I really do not approve your excuses for your adoption of Interprocess Communication(IPC).
You know quite well that context switching can be expensive. Those crash safety issues you raised arent good excuses. Remember Defensive programming and persistent objects?? For scalability reasons, If you have multiprocessing in mind, you would definitely have to localize most of your routines, still needing threads to do that... Running a remote process wouldnt speed up your app without having most routines atomic and local. I know this cause... Theres a project am working on, dynamically processing a file between two entirely different opensource software, in GTK and WxWidgets....

I totally agree with u as regards the kind of system been built but it is important to understand that i was talking about system-level concurrency as opposed to component-level concurrency. If your system is structured internally as a collection of loosely coupled components for example, i find to more useful to impose process-based concurrency at the system-level by mapping each component to its own process and leave the multi-threading decisions to the individual component developers. But if for example your system has a monolithic internal structure where all the system elements inherently share the same process, then u really have no choice but to employ thread-based concurrency at the system-level.

i sure need to go back to school, grammar too much for this place.

webdezzi: i sure need to go back to school, grammar too much for this place.

Don't mind them. The poster has read a lot of jargon on stackoverflow and is vomiting same here. If you want explicit and extensive information go to stackoverflow and hear from those who developed the various languages with their concurrency models.

naija_swag: Don't mind them. The poster has read a lot of jargon on stackoverflow and is vomiting same here. If you want explicit and extensive information go to stackoverflow and hear from those who developed the various languages with their concurrency models.

lol. I have always wondered why that guy can't express himself

lordZOUGA:
lol. I have always wondered why that guy can't express himself

i think the intention here isn't expression but impression.

.

.

its just that what he said, he could have said with fewer sentences....
Besides, if he wasn't ranting and was interested in proving that processes are better than threads, he should have written a test in his favourite programming language or outline a test illustrating what he said above then benchmark the test and provided the result. Thats how science works. I believe there are more developers here than journalists..

webdezzi:
i think the intention here isn't expression but impression.

hahaha.
Just what a friend of mine who saw this post was saying...lol.
Anyway, How sure are you? At least give the OP benefit of doubt.....

Threads make it easier to maintain and access shared data efficiently. Processes provide better isolation. Use what works best for each problem.

harryobas:
I totally agree with u as regards the kind of system been built but it is important to understand that i was talking about system-level concurrency as opposed to component-level concurrency. If your system is structured internally as a collection of loosely coupled components for example, i find to more useful to impose process-based concurrency at the system-level by mapping each component to its own process and leave the multi-threading decisions to the individual component developers. But if for example your system has a monolithic internal structure where all the system elements inherently share the same process, then u really have no choice but to employ thread-based concurrency at the system-level.

i don't exactly know what kind of system you are try to use. But you seem like you want modular entry points into the core process... (maybe Plugins). Sometimes, we are left with the Chicken and the Egg problem... Who came first??
I once checked on the basic plugin architecture of 2 powerful OpenSource projects. Mozilla Firefox and Google Chrome. IF I REMEMBER CLEARLY, Firefox wraps its extension in a plugin-container process, the container acts as an automatic manager and an abstraction of Firefox's api.
Chrome spawns a new wrapper process for any plugin... And all processes still hook on to a specially threaded layer on the main browser process.

I have never developed an Addon for any of them... but I can figure out that Chrome plugins will be by far easier to manage both at Developer and user level, the only drawback is overhead consumption in the 1st data pooling to each process to act on the page... Though, a natural Chrome itself is faster than Firefox... a user wouldn't notice it.

Seun: Threads make it easier to maintain and access shared data efficiently. Processes provide better isolation. Use what works best for each problem.

you are right. Simple and straight forward!! Nice. Further explanation:: Atomic operations... Semaphores in threads are better.
More light to this, ...Its very good to have server management program or suite as different processes but not a sequential and computationally intensive routine, like blurring some frames in a Non Linear Video Editor and playing it in realtime... Here threads wins.

goon:
Please do so if you deem it necessary...

Thanks.

1. Fault-tolerance and scalability is the main advantages of using processes vs. threads.

first off, threads can do anything processes can do, except a situation where your application requires a separate process to manage the main process
e.g you need to close a gui app completely and still require a service to keep running and checking for some update somewhere, so when update arrives, you can relaunch the main application.
asides that, i see no way processes will be better off.
creating processes is similar to opening multiple instance of say "notepad"
making each talk to each other becomes another problem that must be solved

while processes makes it easier to access and share resources within the application and still takes advantage of the features you get when you run multiple instances of same application
besides, threads are more lightweight, creating a basic new thread in python, with no data loaded into it, on my system costs less than 5kb
whereas Google chrome which creates new processes for every new tab has a new tab claiming up 5MB from my RAM

Fault-tolerance? if you handle your exceptions carefully, that should be no issue.
Scalability? I dont get what you mean here, can you clarify? i'll need examples on how and when scaling can be a problem for threaded application over process

3. Another advantage of processes is that they can crash and you are perfectly ok with that, because you just restart them (even across network hosts). If thread crashes, it may crash the entire process, which may bring down your entire application.

well, for the reason your application crashes while using threads is same reason each process will crash.
if you find threads buggy or difficult to implement correctly as you have said. Please consider a toolkit that will take care of it for you.
if you use c++ or python, i'll recommend the Qt's QThread class. it's being simplified into a signal-slot mechanism.
so you dont have to manage mutexes, semaphores etc.

i hope seun is noting the long line text rendering issue above ^

lordZOUGA:
lol. I have always wondered why that guy can't express himself

And I guess u can express yourself right? Mr english guru

lordZOUGA: its just that what he said, he could have said with fewer sentences....
Besides, if he wasn't ranting and was interested in proving that processes are better than threads, he should have written a test in his favourite programming language or outline a test illustrating what he said above then benchmark the test and provided the result. Thats how science works. I believe there are more developers here than journalists..

I am not trying to prove that processes are better threads I am only expressing an opinion based on personal experience u don't have to agree with it as its only an opinion. Besides if u think that I could have used fewer sentences well that's also a matter of opinion and I make no apologies for that.

harryobas:

I am not trying try to prove that processes are better threads I am only expressing an opinion based on personal experience u don't have to agree with it as its only an opinion. Besides if u think that I could have used fewer sentences well that's also a matter of opinion and I make no appologies for that.

hehe... Well said

looks like Unix programming standard advocates strongly for the use of processes over threads.
Excerpts from "Basics of Unix Programming":
Rule of Modularity: Write simple parts
connected by clean interfaces. As Brian Kernighan once observed, “Controlling complexity is the essence of computer programming” [Kernighan-Plauger]. Debugging dominates development time, and getting a
working system out the door is usually less a result of brilliant design than it is of managing not to trip over your own feet too many times. Assemblers, compilers, flowcharting,
procedural programming, structured
programming, “artificial intelligence”, fourth-
generation languages, object orientation, and
software-development methodologies
without number have been touted and sold as a cure for this problem. All have failed as
cures, if only because they ‘succeeded’ by
escalating the normal level of program
complexity to the point where (once again)
human brains could barely cope. As Fred
Brooks famously observed [Brooks], there is no silver bullet. The only way to write complex software that
won't fall on its face is to hold its global
complexity down — to build it out of simple
parts connected by well-defined interfaces, so
that most problems are local and you can have
some hope of upgrading a part without breaking the whole.
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537