From owner-freebsd-arch Tue Nov 30 5:45:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AAEDC158A0 for ; Tue, 30 Nov 1999 05:45:12 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA05857 for ; Tue, 30 Nov 1999 14:45:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA70371 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 14:45:10 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1DC5F158A0 for ; Tue, 30 Nov 1999 05:44:59 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p15-dn01kiryunisiki.gunma.ocn.ne.jp [210.132.6.144]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id WAA25492; Tue, 30 Nov 1999 22:44:53 +0900 (JST) Message-ID: <3843D43E.4F40A642@newsguy.com> Date: Tue, 30 Nov 1999 22:42:22 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > No, it won't, because most context switches are synchronous and > the tick interval doesn't apply in those cases. Asynchronizing > I/O does not necessarily mean that the calling thread will continue to > run. If it has nothing to do it is going to exit or go to sleep whether > the I/O is asynchronous or not. It is definitely not going to waste > cpu finishing out its quanta. Mmmm... that's not exactly what I'm worried about. I'm thinking of applications which use threads to handle both i/o and cpu-bound tasks. Our scheduler raises the i/o-bound tasks priority and lowers cpu-bound tasks priority. With a program using threads to do both, the scheduler would end up treating the process as cpu-bound and lower it's priority. Ok, maybe that's fault of the application design, but still... :-) Processes with enough i/o-bound tasks to actually use up all quanta before running out of threads will suffer from a similar fate. -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message