Path: ...!weretis.net!feeder9.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Fri, 5 Jul 2024 09:59:39 +0200
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <v6895b$36v5v$1@dont-email.me>
References: <v61jeh$k6d$1@gal.iecc.com> <v61oc8$1pf3p$1@dont-email.me>
 <HYZgO.719$xA%e.597@fx17.iad>
 <8bfe4d34bae396114050ad1000f4f31c@www.novabbs.org> <875xtn87u5.fsf@localhost>
 <v62ln0$21r93$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 05 Jul 2024 09:59:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="164b63ebde40e36d0fd4fbf1751c6288";
	logging-data="3374271"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+RVwuDdH9Ib7B/ZUMNcY7E2P3QGaY5bVERSp7KQ/fKHA=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:Vye/Ls2eEUUDY0+zfzdiJwFDH1s=
In-Reply-To: <v62ln0$21r93$1@dont-email.me>
Bytes: 3596

Lawrence D'Oliveiro wrote:
> On Tue, 02 Jul 2024 17:36:50 -1000, Lynn Wheeler wrote:
>=20
>> When doing IBM's HA/CMP and working with major RDBMS vendors on cluste=
r
>> scaleup in late 80s/early 90s, there was lots of references to POSIX
>> light-weight threads ...
>=20
> Threads were all the rage in the 1990s. People were using them for
> everything. One language (Java) absorbed threading right into its core =
DNA
> (where is the locking API? Oh, it=E2=80=99s attached to the base =E2=80=
=9CObject=E2=80=9D type
> itself!).
>=20
> People backed off a bit after that. Nowadays we see a revival of the
> =E2=80=9Ccoroutine=E2=80=9D idea, where preemption only happens at expl=
icit =E2=80=9Cawait=E2=80=9D
> points. For non-CPU-intensive workloads, this is much easier to cope wi=
th.
>=20
>> ... and asynchronous I/O for RDBMS (with no buffer > copies) and the
>> RDBMS managing large record cache.
>=20
> This is why POSIX has the disk-oriented =E2=80=9Caio=E2=80=9D API, for =
the diehard DBMS
> folks. Linux also added =E2=80=9Cio_uring=E2=80=9D, for high performanc=
e but not disk-
> specific I/O.

Really old PC printers (dot matrix or similar) still had a line buffer=20
worth of on-device memory, enough so that the CPU could sit in a buzy=20
loop sending bytes over the Centronix interface until it got the "I'm=20
full" status bit back, or N bytes had been sent. At that point my disk=20
spooler code would back off and let the next timer interrupt check to=20
see if there was both more print data to be sent and the printer=20
signalled that it was ready to receive more data.

The original serial ports had no buffer at all, so you had to use=20
interrupts for both sending and receiving if you wanted to do anything=20
else while communicating. Around 1984 the serial ports gained a 16-byte=20
buffer, so at that time it made sense to use a hybrid approach,=20
filling/emptying the buffer on each interrupt, while reducing the=20
interrupt load by an order of magnitude.

I.e. acting somewhat like a channel program, but using the main/only cpu =

to do all the work in the background.
Terje

--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"