Date: Tue, 30 Nov 1999 10:29:42 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler Message-ID: <199911301829.KAA26530@apollo.backplane.com> References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> <199911301732.JAA25846@apollo.backplane.com> <38441379.D8CD6CCD@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911301829.KAA26530>