The Question is:
My question is about disabling ASTs (with SYS$SETAST) in a multithreaded (DEC
Threads ie. posix) application linked with both upcalls and kernel threads
I am confused about how the threads scheduler issues upcalls. Are upcalls
issued as ASTs? If so, does disabling ASTs mean no upcalls?
I have a specific API that is intended to be used in both multithreaded and
single threaded environments. The API has routines to read and to update
blocks of shared data. The read routines simply call tis_read_lock to lock
the data for read access whil
e the update routines first disable ASTs by calling SYS$SETAST, then call
tis_write_lock. I am concerned that if disabling ASTs also blocks thread
scheduler upcalls, will other threads not get scheduled in a timely fashon if
a thread that has disabled AS
Ts is waiting to aquire a lock?
The Answer is :
For information on mixing ASTs and threads and for various discussions
of same, please see topics including (2790), (3072) and (6099), and
the pointers in these topics.
Related topics include (1661), (2681), (4647), (6984), (7383), and
(8938), among other topics.
Also please see the lock manager, as this can provide synchronization.
In this application, the OpenVMS Wizard would seriously consider the
use of RMS with global buffers enabled, as this approach provides
all needed synchronization for threading and AST-based operations,
fully manages the per-system data cache, and the synchronization is
fully distributed across a cluster. (You might start out with what
appears to be a more light-weight implementation, but may find that
you will eventually find yourself re-implementing what RMS and the
file system -- and global buffers -- already provide for you, and
particularly should you need to implement additional requirements
and distributed synchronization.)