From owner-freebsd-hackers  Mon Sep 23 23:57:14 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA04317
          for hackers-outgoing; Mon, 23 Sep 1996 23:57:14 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA25236;
          Mon, 23 Sep 1996 23:38:54 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id XAA00598; Mon, 23 Sep 1996 23:38:00 -0700 (PDT)
Message-Id: <199609240638.XAA00598@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
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. 
In-reply-to: Your message of "Tue, 24 Sep 1996 09:14:14 +0900."
             <Pine.SV4.3.93.960924085722.18016A-100000@parkplace.cet.co.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 23 Sep 1996 23:37:59 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>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