  Help locating a lost locking AST? 
 The Question is:
 
Mr. Wizzard...
A question involving Blocking ASTs:
I have a process showing a lock granted at CW and status = BLASTQD (as
expected).  The process is in CEF state (expected) and AST active (from SDA)
is NONE. and ASTs remaining are 500 (none outstanding)
The routine does disable AST and re-enable them and I am fairly certain they
are enabled at this point (Any way to prove this in SDA?)
 
Why is the BLAST not being delivered?
 
Background:
 
I have a number of processes sharing a number of global sections. Each
section has a conceptual owner. The owner gets a lock in EX mode and then
must create and populate the section. When it does, releases the lock with
the section size in the LVB. All ot
her users of the section map and acquire the lock with a blocking AST
enabled. SHould the section nedd to be resized, the 'owner' requests the
lock in EX mode causing the blast to be dlivered and the other process
withdraw from the section. The resize is
done and the lock released with the new size and all other processed are
regranted the lock at CW again. Works almost all the time.
 
I will try pasting in the process info from SDA  and hope it comes out on
your screen OK.
 
Many thanks
 
Paul
 
Process index: 002B   Name: EMU_RELATER   Extended PID: 202002AB
----------------------------------------------------------------
Process status:          00140001  RES,PHDRES,LOGIN
        status2:         00000001  QUANTUM_RESCHED
 
PCB address              814B3300    JIB address              814C4C80
PHD address              82A18000    Swapfile disk address    00000000
KTB vector address       814B35EC    HWPCB address            82A18080
Callback vector address  00000000    Termination mailbox          0491
Master internal PID      0005002B    Subprocess count                0
Creator extended PID     00000000    Creator internal PID     00000000
Previous CPU Id          00000000    Current CPU Id           00000000
Previous ASNSEQ  0000000000000008    Previous ASN     0000000000000028
Initial process priority        4    Delete pending count            0
# open files allowed left     198    Direct I/O count/limit        200/200
UIC                [00001,000004]    Buffered I/O count/limit    50000/50000
Abs time of last event   0AF54B66    BUFIO byte count/limit
995072/995072
ASTs remaining                500    # of threads                    1
Swapped copy of LEFC0    00000000    Timer entries allowed left    100
Swapped copy of LEFC1    00000000    Active page table count         0
Global cluster 2 pointer 00000000    Process WS page count          44
Global cluster 3 pointer 8141E580    Global WS page count          282
 
 
Extended PID: 202002AB     Thread index: 0000
---------------------------------------------
Current capabilities:    System: 0000000C  QUORUM,RUN
                         User:   00000000
Permanent capabilities:  System: 0000000C  QUORUM,RUN
                         User:   00000000
Current affinities:      00000000
Permanent affinities:    00000000
Thread status:           00140001
       status2:          00000001
 
KTB address              814B3300    HWPCB address            82A18080
PKTA address             7FFEFF98    Callback vector address  00000000
Internal PID             0005002B    Callback error           00000000
Extended PID             202002AB    Current CPU id           00000000
State                       CEF      Flags                    00000000
Base priority                   4    Current priority                5
Waiting EF cluster              3    Event flag wait mask     FFFDFFFF
CPU since last quantum       FFFD    Mutex count                     0
ASTs active                  NONE
 
 
 The Answer is:
 
  This is almost undoubtedly a programming error, as the particular
  approach described here is quite commonly (and successfully) used
  in a large number of applications.
 
  SDA can be used to display which ASTs are enabled within the process,
  this information is visible in the process header display of SHOW
  PROCESS/ALL.
 
  The disabling of AST reception should be performed with caution, as
  the timing of the reception of an AST within the processing that
  performs the "disable" operation is potentially interesting.  For
  short sequences where interruptions should be disabled, the use of
  an AST (via sys$dclast) can be used to synchronize all shared variable
  access to AST-mode routines.
 
  The OpenVMS Wizard would recommend reviewing responses 1661 and 2681,
  and would also recommend simplifying the interlocking protocol as much
  as possible, and creating a short, standalone example of the application
  environment.  This will help you review the sequences that can arise,
  and to look for "holes" in the locking protocol.  In particular in
  this case, concentrate on the sections that disable AST reception.
  (In many applications, the use of interlocked queue instructions or
  PALcode calls and "careful updates" are used to entirely avoid the
  need to disable AST reception over short "critical" code sequences.)
 
  The OpenVMS Wizard does not generally recommend mixing event flags
  (event flags as a communications mechanism) and ASTs within the same
  application, prefering to use event flags (only) for simple in-line
  routine completion checks and particularly using the "don't care"
  EFN$C_ENF "event flag" whenever possible.
 
  All this written, unfortunately, these synchronization errors and race
  conditions can be quite difficult to locate.  The OpenVMS Wizard often
  uses integrated logging -- tools built directly into the application --
  to selectively enable and log the activity as it occurs.  This logging
  can be useful when tracking down subtle errors.
 
