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