Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!DGOGWD01.BITNET!GWD21T
From: GWD21T@DGOGWD01.BITNET
Newsgroups: mod.computers.vax
Subject: MAIL
Message-ID: <8608142234.AA03262@ucbvax.Berkeley.EDU>
Date: Thu, 14-Aug-86 18:35:58 EDT
Article-I.D.: ucbvax.8608142234.AA03262
Posted: Thu Aug 14 18:35:58 1986
Date-Received: Fri, 15-Aug-86 05:30:39 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 27
Approved: info-vax@sri-kl.arpa


Re: Critical Regions under VMS

The worst problem with critical regions comes from the $DELPRC system
service which is NOT A PRIVILEGED request (the owner can $ STOP
a process from any other terminal).
With $DELPRC, NO exit handler is ever executed, so you can't rely
on an exit handler at all.
The 2nd solution given by Greg W. from DEC (raising priority to IPL$_ASTDEL)
is correct only if you need no cleanup later, so it does not satisfy
the original submitter's requirement. By the way, I might prefer
to put the critical region into a kernel AST instead of
raising the IPL, so I need not care for page faults.

For cleanup at image/process termination, however, only the "User rundown"
routine available for privileged shareable images is guaranteed to run
within process context (remember the V.3 "Real-Time User's Guide"?).
I think that such a "user written system service" is about the only
solution.
For a more elaborate scheme, I could imagine a separate process
monitoring access to the critical regions; this process could be
triggered after image/process rundown via the lock manager, and
do the cleanup required.
                                        W.J.M.

J.W.Moeller, GWDG, D-3400 Goettingen, F.R.Germany  GWD21T@DGOGWD01.BITNET
                                                    Phone +49-551-201516