HP OpenVMS Systems

Distributed Lock Manager Primer?

» close window

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.
 

  

     

     
answer written or last revised on ( 3-JAN-2002 )
     
» close window