just an aside on asynchronous i/o: concurrency by asychronous I/O actually
predates concurrency via thread-like models, and goes back to the earliest
OS-precursors. Early work on thread-like concurrency models were, in part,
a response to the difficulties inherent in getting asynchronous I/O right,
and so now the pendulum is swinging back.
A pedantic nit: the basic Un*x I/O model, with syncrhronous interfaces
predates Un*x networking by some time. I woudl make the case that the
people who grafted Un*x networking (most notably sockets) onto Un*x didn't
really understand the I/O model, and crafted cruft, that just happened to
have a few usable features, one being a sort-of way of sometimes getting
asynchrony.
Prior to posix, by the way, there were any number of Un*x variants that
asynchronous I/o models, supporting any number of i/o completion
notification models, buffering schemes and (lack of) cancellation semantics.
My personal favorite was the variant in the Cray-2 Unicos; my personal least
favorite was Intergraph's Clix.
Marty
-----Original Message-----
From: Dan Maas [mailto:dmaas@dcine.com]
Sent: Friday, September 01, 2000 11:50 PM
To: linux-kernel@vger.kernel.org
Subject: Re: thread rant [semi-OT]
[...]
Can we do better? Yes, thanks to various programming techniques that allow
us to keep more of the system busy. The most important bottleneck is
probably the network - it makes no sense for our server to wait while a slow
client takes its time acknowledging our packets. By using standard UNIX
multiplexed I/O (select()/poll()), we can send buffers of data to the kernel
just when space becomes available in the outgoing queue; we can also accept
client requests piecemeal, as the individual packets flow in. And while
we're waiting for packets from one client, we can be processing another
client's request.
The improved program performs better since it keeps the CPU and network busy
at the same time. However, it will be more difficult to write, since we have
to maintain the connection state manually, rather than implicitly on the
call stack.
So now the server handles many clients at once, and it gracefully handles
slow clients. Can we do even better? Yes, let's look at the next
bottleneck - disk I/O. If a client asks for a file that's not in memory, the
whole server will come to a halt while it read()s the data in. But the
SCSI/IDE controller is smart enough to handle this alone; why not let the
CPU and network take care of other clients while the disk does its work?
How do we go about doing this? Well, it's UNIX, right? We talk to disk files
the same way we talk to network sockets, so let's just select()/poll() on
the disk files too, and everything will be dandy... (Unfortunately we can't
do that - the designers of UNIX made a huge mistake and decided against
implementing non-blocking disk I/O as they had with network I/O. Big booboo.
For that reason, it was impossible to do concurrent disk I/O until the POSIX
Asynchronous I/O standard came along. So we go learn this whole bloated API,
in the process finding out that we can no longer use select()/poll(), and
must switch to POSIX RT signals - sigwaitinfo() - to control our server***).
After the dust has settled, we can now keep the CPU, network card, and the
disk busy all the time -- so our server is even faster.
[...]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 02 2000 - 19:41:51 EDT