Re: Dahm Locks
- From: "Paul Skykiss" <paul.skaistis@xxxxxxxxxxxxx>
- Date: Sun, 7 Dec 2008 19:38:19 -0800
Like Edward, I won't respond to the sections I agree with, but I'll add some
comments about "why DSIALLOW?"
"Paul Kimpel" <paul.kimpel@xxxxxxxx> wrote:
Edward raises some interesting points, to which I'll reply in context<< snip >>
On 12/3/2008 8:45 PM, Edward Reid wrote:
I won't quote or respond to the sections of Paul's discussion I
completely
agree with -- that's the vast majority and I'd wear my fingers out typing
"I agree".
On Tue, 11 Nov 2008 00:28:41 -0800, Paul Kimpel wrote:
ACQUIRELOCK (ID) =
BEGIN
DISALLOW;
IF READLOCK(PROCESSID, CONTENDERS[ID]) ^= 0 THEN
DO
PROCURE(LOCKS[ID])
UNTIL READLOCK(-1, CONTENDERS[ID]) = 0;
OWNERS[ID]:= PROCESSID;
ALLOW;
END#,
RELINQUISHLOCK (ID) =
BEGIN
DISALLOW;
OWNERS[ID]:= 0;
IF READLOCK(0, CONTENDERS[ID]) ^= PROCESSID THEN
LIBERATE(LOCKS[ID]);
ALLOW;
END#,
I'm blanking, though, on the reason for the DISALLOW/ALLOW. It isn't to
prevent another process from sneaking in between operations -- READLOCK
prevents that for the single memory exchange, but outside that, the
DISALLOW doesn't prevent other CPUs from accessing the same memory in
parallel. And PROCURE is almost guaranteed to release the CPU. All that's
stopped is *external* interrupts -- mostly I/O interrupts. The reasoning,
I
think, must be that for the purposes of these locks, an I/O interrupt
could
conceivably cause this same code to be entered higher on the same stack
as
part of processing the interrupt. This would be conceivable for the DMSII
Accessroutines, but user programs would not need to be concerned about
that
possibility. But I may be missing something.
This is an excellent observation. I knew and could explain at one time why
DISALLOW/ALLOW were necessary, but I think that portion of my gray matter
evaporated when I turned 30.
These defines came from a file of sample COMS processing items that I
believe were originally distributed by one of the MCP customer support
centers. I can't find that file, but a note in the library from which I
extracted them says it was named PROCESSINGITEMS/LAKEFOREST/VERSION10. I'm
certain the ALLOW and DISALLOW were in the original code, and that I
wasn't brave enough to mess with them (having been over 30 at the time).
I have a vague recollection that the purpose of disabling external
interrupts had less to do with I/O interrupts than with disabling
processor-to-processor interrupts (which on the B6700, at least, was
implemented with the HEYU operator; modern systems have a different
mechanism). I think DEXI (the instruction corresponding to DISALLOW) also
disabled the interval timer interrupt.
The DISALLOW is to (from the source code comment):
"... ensure that locking TTL and identifying the owner of TTL is an atomic
operation, we need to disable external interrupts in this code."
The practical motivation is to prevent an OPERATOR DS from breaking the
atomicity of the code. When this is implemented in a shared library (with
perhaps hundreds, and over time tens of thousands of clients), keeping lock
ownership clear is essential.
INTERLOCKS, mention elsewhere in this thread avoid the hard coding UNSAFE
constructs like DISALLOW. It also (as Paul Kimpel further described) uses
READLOCK, but now it is now generated by the compilier. If a better
solution becomes available, the compilier can generate the new alternative.
That said, the "hand coded" approach still works. On machines with either a
hardware or emulated Task Control Unit (TCU), INTERLOCKS take contending
process priority into account and are not UNSAFE and therefore available in
plain ALGOL.
BTW the source the Paul mentioned is available from the Unisys Product
Support web site.
<other excellent observations and comments removed>
.
- Follow-Ups:
- Re: Dahm Locks
- From: Paul Kimpel
- Re: Dahm Locks
- References:
- Re: Dahm Locks
- From: Edward Reid
- Re: Dahm Locks
- From: Paul Kimpel
- Re: Dahm Locks
- Prev by Date: Re: Dahm Locks
- Next by Date: Re: Old was : Anybody know sources for Univac ...Word Size
- Previous by thread: Re: Dahm Locks
- Next by thread: Re: Dahm Locks
- Index(es):
Relevant Pages
|
