Date: Mon, 23 Sep 1996 23:37:59 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Michael Hancock <michaelh@cet.co.jp> Cc: Terry Lambert <terry@lambert.org>, freebsd-smp@freebsd.org, FreeBSD Hackers <Hackers@freebsd.org> Subject: Re: multithreading in the kernel and applications. Message-ID: <199609240638.XAA00598@rah.star-gate.com> In-Reply-To: Your message of "Tue, 24 Sep 1996 09:14:14 %2B0900." <Pine.SV4.3.93.960924085722.18016A-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
>From The Desk Of Michael Hancock : > [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. Yes, I can imgine such programs as "team" or an osi file server which I work on 10 years ago for VMS . A single file server was able to serve up multiple connections with no problems . Regards, Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609240638.XAA00598>