|
HP OpenVMS Systemsask the wizard |
|
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.
|