From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA12468; Wed, 19 Feb 2003 19:18:05 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA12393 for ; Wed, 19 Feb 2003 19:18:02 +0100 (MET) Received: from norm.cs.wisc.edu (norm.cs.wisc.edu [128.105.6.22]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h1JII0P26360 for ; Wed, 19 Feb 2003 19:18:00 +0100 (MET) Received: from tux15.cs.wisc.edu (tux15.cs.wisc.edu [128.105.111.115]) by norm.cs.wisc.edu (8.9.2/8.9.2) with ESMTP id MAA26407; Wed, 19 Feb 2003 12:17:58 -0600 (CST) Received: (from willb@localhost) by tux15.cs.wisc.edu (8.9.2/8.9.2) id MAA02641; Wed, 19 Feb 2003 12:17:56 -0600 (CST) Date: Wed, 19 Feb 2003 12:17:56 -0600 From: Will Benton To: Brian Hurt Cc: ranjan.bagchi@frotz.com, caml-list@inria.fr Subject: Re: [Caml-list] Re: feature priorities (multithreading) Message-ID: <20030219121756.C2587@tux15.cs.wisc.edu> References: <20030219171419.95167.qmail@web13808.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from brian.hurt@qlogic.com on Wed, Feb 19, 2003 at 11:45:52AM -0600 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, Feb 19, 2003 at 11:45:52AM -0600, Brian Hurt wrote: > A better approach is what's called the M-by-N approach. You have M kernel > level threads (so you can take advantage of M parallel CPUs) each > executing threads from a pool of N user space threads. This gives you the > best of both worlds. Not necessarily -- most m:n threads packages have non-preemptive user thread schedulers, which means that a compute-intensive user thread that never enters the kernel and doesn't yield the processor can monopolize a kernel thread. That might be a pathological example (since if you're trying to run >N compute-intensive threads on N processors, you're in trouble), but someone might argue that an application that context-switches enough to *require* m:n instead of 1:1 is pathological in a different way. If you need preemptability, then the best-of-both-worlds approach is to find a system on which kernel thread context switches are cheap. :-) (Making KT switches cheap seems to be the direction that the industry is going -- Sun, for example, has dropped their m:n threads package for solaris.) best, wb --- Will Benton willb@acm.org ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners