Re: threads vs. processes
From: David Schwartz (davids_at_webmaster.com)
Date: 05/03/03
- Next message: DJKapi: "c++"
- Previous message: David Schwartz: "Re: threads vs. processes"
- In reply to: Barry Margolin: "Re: threads vs. processes"
- Next in thread: Valentin Nechayev: "Re: threads vs. processes"
- Reply: Valentin Nechayev: "Re: threads vs. processes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 3 May 2003 01:05:16 -0700
"Barry Margolin" <barry.margolin@level3.com> wrote in message
news:lbDsa.22$ve7.1879@paloalto-snr1.gtei.net...
> In article <b8urg8$ran$1@nntp.webmaster.com>,
> David Schwartz <davids@webmaster.com> wrote:
> > Definitely. User mode threads are, IMO, almost totally useless. The
main
> >reason people use threads (and this is certainly true in server
> >applications!) is to avoid stalling their entire application when they
> >block. Why take all the penalties and costs of threads if you don't get
the
> >primary benefit -- multiple executionn vehicles?!
> I always thought that the "main reason" threads were developed is because
> it simplifies programming. Rather than writing your own event loop and
> maintaining state objects for all your activities, you can just write a
> function that handles a single activity and spawn a thread to run it. The
> state can be maintained in normal local variables. You can program almost
> as if there's just one activity going on; you only have to do anything
> special when the threads interact with each other (which is simplified
> compared to processes because they share an address space).
Perhaps in Java, but you don't see many C/C++ programmers saying, "I
like to use multithreading because it makes things so easy". Even in
single-threaded programming, it's bad form to use the stack to hold context,
as bad as global variables.
> Kernel-mode threading is a relatively recent optimization to this. Also a
> recent issue is applications which would have so many threads if they
> followed the naive model above that they would overload the system.
That's
> when you have to go to the thread pool model, which necessitates
> resurrecting state objects that can be passed to the thread as a
parameter;
> in this case, you generally need kernel-mode threading because you're
> mainly using threads as a fine-grained time-slicing mechanism, not as a
> programming abstraction.
People use threads for all sorts of things. What they're really useful
for depends upon what types of problems you have.
I have written single-process, single-thread poll/select type
applications for a very long time. As load increases, they become extremely
bursty. This is in fact due to ambush. Multithreading allows you to solve
this ambush problem even in cases where using distinct processes is
impractical due to the amount of data sharing.
It is also convenient to not have to worry that if your application ever
blocks in any place at all, you're performance is utterly hosed.
Multithreading gives you this for free. So to that extent, multithreading
does make programming easier.
However, using threads to correspond directly to things like clients is
just sloppy. They're abstractions of different things. Threads are execution
vehicles and you should create as many as you actually need execution
vehicles.
- Next message: DJKapi: "c++"
- Previous message: David Schwartz: "Re: threads vs. processes"
- In reply to: Barry Margolin: "Re: threads vs. processes"
- Next in thread: Valentin Nechayev: "Re: threads vs. processes"
- Reply: Valentin Nechayev: "Re: threads vs. processes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
