On Jun 2, 2:22=A0pm, jbaker...@[EMAIL PROTECTED]
(John P. Baker) wrote:
> I seem to recall something called the "Limited Lock Facility (LLF)",
which=
> provided some specialized CCW sup****t in the controller.
>
> Was it developed for use in situation such as that described here?
http://www.garlic.com/~lynn/2008i.html#19
American Airlines
http://www.garlic.com/~lynn/2008i.html#34
American Airlines
http://www.garlic.com/~lynn/2008i.html#36
American Airlines
http://www.garlic.com/~lynn/2008i.html#37
American Airlines
http://www.garlic.com/~lynn/2008i.html#38
American Airlines
note by comparison, reserve will be a CCW that "locks" the whole
device
=2E.. which typically will be followed by some sort of seek/search/read.
That ends and the processor then operates/updates the data read and
then writes it back ... finally releasing the device.
The other approach mentioned ... developed at HONE was simulation
of multiprocessor compare&swap instruction ... using "search key& data
equal" ... the data is read (w/o lock or reserve), a copy is made and
the
update is applied. then a channel program with search key&data equal
=2E.. using the original read image .... chained to write of the updated
data.
the following from long ago and far away ...
Subject: DASD sharing in ACP using the RPQ
Date: March 25, 1980
On Monday I bumped into xxxx & yyyy. They were both interested in
shared DASD for availability and load sharing. I mentioned the ACP
RPQ which puts a lock manager in the microcode for the disk
controller. They were real interested in that and so I began
telephoning.
My first contact was xxxxx of GPD San Jose who wrote the microcode
(nnn-nnnn). He explained that the RPQ "has a low profile" because it
is not part of the IBM strategy and is inconsistent with things like
string switching. The basic idea is that Lock commands have been
added to the controller's repertoire of commands. One issues LOCK
READ CCW pair and later issues WRITE UNLOCK CCW pair. If the lock
fails the read fails and the CPU will poll for the lock later. xxx
has do***ented all this in the technical re****t TR 02.859 "Limitied
Lock Facility in a DASD Control Unit" xxxxx, xxxxx, xxxxx (Oct. 1979).
xxx pointed me to xxx xxxxx at the IBM Tulsa branch office (nnn-nnnn).
xxxx wrote the channel programs in ACP which use the RPQ. He said
they lock at the record level, and that it works nicely. We also
discussed restart. He said that the code to reconfigure after CPU or
controller failure was not hard. For duplexed files they lock the
primary if available, if not they lock the secondary. ACP allows only
one lock at a time and most writes are not undone or redone at restart
(most records are not "critical"). xxx said that their bigist problem
was with on-line utilities. One which moves a volume from pack to
pack added 50% to their total effort! xxx in turn pointed me to two
of the architects.
xxxxxx at White Plains DPD (nnn-nnnn) knows all about ACP and promised
to send me the do***entation on the changes to ACP. He said the
changes are now being integrated into the standard ACP system. He
observed that there is little degradation with the RPQ and prefers it
to the MP approach. He mentioned that there are about 65 ACP
customers and over 100 ACP systems. xxxxx is also at White Plains
(nnn-nnnn). He told me lots of numbers (I love numbers).
He described a 120 transaction/second system.
The database is spread over about 100 spindles.
Each transaction does 10 I/O.
10% of such I/O involve a lock or unlock command.
The average hold time of a lock is 100 ms.
1.7 lock requests wait per second.
That implies that 14% of transactions wait for a lock.
This is similar to the System R number that 10% of transactions wait.
ACP has deadlock avoidance (only hold one lock at a time).
There are 60 lock requests per seconds (and 60 unlocks) and so there
are about 6 locks set at any instant.
This is not a heavy load on the lock managers (a controller is likely
to have no locks set.)
=2E.. snip ...
|
