Re: threads vs. processes

From: David Schwartz (davids_at_webmaster.com)
Date: 05/03/03 

Date: Fri, 2 May 2003 15:29:27 -0700

"Barry Margolin" <barry.margolin@level3.com> wrote in message
news:vTzsa.15$ve7.1261@paloalto-snr1.gtei.net...

> In article <b8ugtb$l45$1@nntp.webmaster.com>,
> David Schwartz <davids@webmaster.com> wrote:

> >With a sensible multithreaded approach, you generally become more
> >efficient as load increases. When one of your I/O threads gets scheduled,
it
> >can do more work in the same timeslice, thus increasing the work done per
> >context switch and improving cache efficiency.

> Hmm. The first message you posted (in this thread) about ambush problems
> said that using *processes* rather than threads is the way to improve
> performance. The example you gave was the process being delayed while it
> faults in the pages for unusual activity; the implication was that this
> affects all the threads of the process.

    I was responding to a post advocating a poll or select loop type
application with just a single execution vehicle. You can avoid ambush with
a multiprocess or multithread approach.

> I think this issue depends on whether threads are scheduled indepently by
> the kernel or they're a user-mode implementation.

    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?!

    DS