From owner-freebsd-hackers Mon Sep 23 18:21:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA13560 for hackers-outgoing; Mon, 23 Sep 1996 18:21:49 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA05395; Mon, 23 Sep 1996 17:59:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA03200; Mon, 23 Sep 1996 17:58:17 -0700 From: Terry Lambert Message-Id: <199609240058.RAA03200@phaeton.artisoft.com> Subject: Re: multithreading in the kernel and applications. To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 23 Sep 1996 17:58:17 -0700 (MST) Cc: terry@lambert.org, freebsd-smp@freebsd.org, Hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Sep 24, 96 09:14:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Consider a "team" program written using async I/O instead of using > > multiple processes (or threads). It can "read" as fast as it can > > queue the system calls, and it can "write" as fast as the buffer data > > from the reads becomes valid. The reads and writes occur concurrently, > > but only a single read and a single write (of different buffers) > > effectively occur in parallel. > > Interesting, I read another message, that I've lost, where you were > griping about UI threads starving for CPU. M LWP's (kernel threads), N > user threads where N > M, N-M threads starve, etc. Yes. This is my favorite "stump the USL threads guys" argument. 8-). > One view of concurrency in this model is the ability of a process to fill > its quantum. i.e. a multi-threaded process with one LWP uses the user > thread scheduler to schedule an available thread when the current thread > blocks without having to make a context switch. Yes. That's the one I advocate. You want to fill as much of your quantum as possible given the task you are mapping quantum into, not dependent upon the system call interface. > I think your message was implying that that UI threads don't work as > designed and are broken. More that kernel threads don't work as designed, and are broken. The POSIX threading is OK -- as far as it goes, since for some things it's concurrent. But given a choice, I'd pick user threads over kernel threads. > Your model, Plan 9?, assumes a 1 to 1 mapping of kernel threads to user > threads and the argument to the context switching overhead is to fix the > context switching overhead so that performance isn't an issue. No? Actually, I'd like to see the thread blocked at the system call interface; I guess, technically, this would be kernel threading because the thread scheduler would be in system space. But like the FreeBSD SMP as it currently stands, the reentrancy would not go below the trap code. So you'd convert a blocking call into a non-blocking call, the generation of a context record, and a context switch (which would be active on the call return to user space. The difference here is that system calls would *always* be non-blocking. This beats the PTHREADS stuff by a large number of potential blocking operations which can be converted instead of some trivial I/O operations and little else. I implemented a prototype in prerelease UnixWare 2.x; I'll probably get around to reimplementing it for FreeBSD some day soon. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.