Date: Mon, 23 Sep 1996 17:58:17 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: terry@lambert.org, freebsd-smp@freebsd.org, Hackers@freebsd.org Subject: Re: multithreading in the kernel and applications. Message-ID: <199609240058.RAA03200@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.93.960924085722.18016A-100000@parkplace.cet.co.jp> from "Michael Hancock" at Sep 24, 96 09:14:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609240058.RAA03200>