From owner-freebsd-arch Tue Nov 30 10:15:10 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 2FD5815985 for ; Tue, 30 Nov 1999 10:15:02 -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 TAA09653 for ; Tue, 30 Nov 1999 19:14:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71755 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:14:58 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 560B11599A for ; Tue, 30 Nov 1999 10:14:50 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (dcs@p13-dn02kiryunisiki.gunma.ocn.ne.jp [210.163.200.110]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id DAA03928; Wed, 1 Dec 1999 03:14:43 +0900 (JST) Message-ID: <38441379.D8CD6CCD@newsguy.com> Date: Wed, 01 Dec 1999 03:12:09 +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> <3843D43E.4F40A642@newsguy.com> <199911301732.JAA25846@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: > > I don't think you have anything to worry about. A thread is going to go > to sleep if it has nothing to do even if all the I/O is asynchronous > (i.e. thread is mixing cpu and I/O bound elements). It isn't the I/O > that raises the priority, it is the act of the process going to sleep > that raises the priority. Perhaps there is a misunderstanding here. It is my impression that the scheduler will not see these threads going to sleep, it will only see a process use all it's quanta instead of going to sleep, because the process always get control back from the kernel whenever a blocking operation happens, and in the end, a cpu-bound thread will finish up the quanta the i/o-bound threads didn't. That's one thing people have been asking for, that the kernel never puts a process to sleep but instead return control to the process as long as it has quanta remaining. -- 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