From owner-freebsd-arch Tue Nov 30 10:30:41 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 87360159B1 for ; Tue, 30 Nov 1999 10:29:58 -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 TAA09846 for ; Tue, 30 Nov 1999 19:29:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71924 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:29:57 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CAA44159B1 for ; Tue, 30 Nov 1999 10:29:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA26530; Tue, 30 Nov 1999 10:29:42 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 10:29:42 -0800 (PST) From: Matthew Dillon Message-Id: <199911301829.KAA26530@apollo.backplane.com> To: "Daniel C. Sobral" 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> <38441379.D8CD6CCD@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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) You are assuming that the application somehow requires more cpu in a threaded environment verses an unthreaded environment. I am saying that when you finish up tallying all the cpu the application uses, it is going to be nearly the same whether the application serializes the system calls (i.e. unthreaded) or doesn't serialize the system calls. From the point of view of the UNIX scheduler. Remember that the kernel already heavily caches and buffers I/O -- for example, writes to a TCP socket, or reads from a TCP socket after data has already been received to it. Most I/O related system calls either return immediately with the data you want, or the blocking case is one that even a threaded application may eventually have to wait for an event on (i.e. it may block, just not necessarily at the time the I/O is issued). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message