Date: Tue, 24 Sep 1996 09:14:14 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: freebsd-smp@freebsd.org, FreeBSD Hackers <Hackers@freebsd.org> Subject: Re: multithreading in the kernel and applications. Message-ID: <Pine.SV4.3.93.960924085722.18016A-100000@parkplace.cet.co.jp> In-Reply-To: <199609232155.OAA02880@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Cross-posted to hackers, I lost the relevant thread there.] On Mon, 23 Sep 1996, Terry Lambert wrote: > > > For us, the ability to support multiple kernel contexts means that > > > it would be a good idea to let the kernel be per CPU reentrant to > > > get us the greatest possible concurrency. > > > > > > > Don't you mean parallelism instead of concurrency? > > No. Parallelism does not cover interleaving I/O in a single thread > (making that thread more concurrent). The thread that makes the > requests would be inherently parallel already, since the task which > it wishes to accomplish is capable of being parallelized. The degree > to which it actually gets parallelized in practice is its concurrency. > > 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. 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. I think your message was implying that that UI threads don't work as designed and are broken. 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? Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960924085722.18016A-100000>