 |
The Question is:
Assume that another process than my current process has qeued a lock, and this
lock has been granted by the lock manager.
The other process is not doing its housekeeping and lets the lock standing.
I would like to clean up from my process and dequeue the lock using the $DEQ
service.
I have read the text in the system service user manual and in the vms
programming concepts manual and I find it somewhat confusing.
The text says that only not granted locks can be dequeued by $DEQ, and a bit
further on that all locks will be dequeued by $DEQ.
Anyway, I tried retrieved the LOCKID through $GETLKI Service and tried to
dequeue it with $DEQ. (see above Code snippet). The service terminates with
%IVLOCKID, invalid lock ID.
Do I have to convert the lock first to another state before I can dequeue it,
or is it not possible to dequeue a granted lock from another Process? I tried
the $DEQ Call with no Flags, and with Flag LCK$M_DEQALL and without Flags.
The Answer is :
The OpenVMS distributed lock manager (DLM) requires (and assumes)
cooperative processing -- only through cooperation can the DLM provide
process coordination. Applications simply do not expect that (granted)
locks will be grabbed out from underneath the application, nor that the
(granted) locks will be arbitrarily overridden -- this "anti-social"
locking behaviour would obviously risk data corruptions, of course.
The lock manager system services $enq, $enqw, $deq, and $deqw act (only)
upon locks held by or requests queued by the local process. The grant
of, release of, or the queuing of a request for a particular lock resource
name is visible to all other (cooperating) processes in the cluster, of
course.
To act upon the locks held by another (and recalcitrant, in this case)
process, you will want to delete the process (which will trigger the
release of all locks held by that process during the process rundown
operations), or you will need to request the cooperation of the process
(via locks, via blocking locks, or via other inter-process communications
mechanisms), or you will need to rework the application code that is
operating in the target process.
The easiest approach involves the use STOP or $delprc on the target
process and (in the longer term) fixing the code, in other words.
Related topics include (318), (2027), (2373), (3079), (3169), (3320).
(3498), (5870), (6643), (6984)
Other related topics include (2681) and (5199) may be of interest, and
some general programming tips for asynchronous programming are in topic
(1661). Details of achieving thread-reentrancy and the associated
locking are referenced in topics (4647) and (6099).
The OpenVMS Wizard here deliberately ignores the possibilities of
releasing the lock through an inter-process inner-mode AST -- this
approach requires extensive knowledge of the OpenVMS operating system
kernel, and certainly risks crashing the OpenVMS system during testing
and debugging.
Various updates to the OpenVMS Programming Concept materials have been
completed in recent releases, and additional changes are underway.
Specific suggestions or confusions should be forwarded directly to
the OpenVMS Documentation team via the mail address in the preface.
|
|
|
|
|
