Printable View
I have to develop a telphonic system that handled 30 simultaunius calls.
The server is dedicated just to this task. I can develop the system using just un procees and create the threads as needed or I can created a central application that trigger un process per call.
My cuestion is: from the point of view of the CPU and OS (in this case Windows 2000) what will be the more reliable aproach.
For Windows it's almost always going to be the case that a thread based solution is going to be less resource intensive than a process based solution.
John
[email protected]
Please, could you give me a more technical reason.
Well, multiple threads is usually a better option because it requires fewer system resources than managing processes.
Like for example creating a thread only requires the allocation of the thread's private data area while creating a process is far more expensive. SO .. multiple threads = better memory management.
Also, creating threads is faster than creating processes, you can kill them just as fast and threads can communicate with each other.
In terms of scheduling, most OS'es do a very good job with threads.
Under Windows, a process is MUCH more expensive than a thread, it terms of both memory and CPU cycles. For the CPU to do a context switch from one thread to another is almost nothing compared to do the same context switch from one process to another. It's really an enormous difference when you get right down to it. That's the simple explanation without getting into page faults and the process space complexities that are at the core of this issue.
You really have to look at your problem and see how it breaks down to figure out what type of solution will work best. It may be possible that you only need one or two threads to handle that many concurrent tasks. That is, if the state machine for your system lends itself to that type of design. Just look at most modern web servers, if they were to spawn a thread per connection, most servers would die under the load of only a few hundred users, and I really doubt you'd get more than a hundred concurrent users if you went with a process per connection. The scalable solution is to use a small pool of threads to handle all the work. It all comes down to the design of the system, in the case of high performance, high reliability applications, design is everything.
Of course, everything I've said is null and void when applied to the UNIX environment, where processes are the preferred method of multi-tasking.
John
[email protected]
I want to clear out that is proccesses are prefered not because they are better but because in Unix (or variants) concurrent programming can be quite difficult, and much of theQuote:
Of course, everything I've said is null and void when applied to the UNIX environment, where processes are the preferred method of multi-tasking.
is still not thread-safe.
Heck, I think that there is still no memory protection between two threads. If one screws the memory then the others will die with it.