|
HP OpenVMS Systemsask the wizard |
|
The Question is: Mr Wizard, Ref: WIZ_5843 (thanks for the reply) In my previous question a wizard said... >> The aio POSIX.4 routines are part of the existing POSIX environment, >> and are also part of the new DII COE work. Does the "existing POSIX environment" mean it's available NOW, prior to DII COE, if so where can I get it for OpenVMS V7.2-1 ? In the same topic, it was also stated that... >> The difficulties involved in mixing DECthreads and ASTs are inherent >> in the internal implementations of DECthreads and of ASTs. Since asynchronous I/O via the AIO_xxx routines and Pthreads can be mixed, does this imply that AST's + Pthreads will be able to be mixed as well with the DII COE implementation ? thanks inadvance -Fred The Answer is : A POSIX kit is (was) available on older OpenVMS releases, but it is not available on OpenVMS V7.2-1, and existing POSIX kits are not compatible with OpenVMS V7.2-1, and are no longer supported. DII COE (V7.2-6C1) is in beta-test at present, integration of the DII COE work back into the OpenVMS mainline releases is not expected prior to OpenVMS V7.4 -- at the earliest. There may be an updated POSIX kit for OpenVMS V7.2-1 or V7.3, but -- assuming that a decision is made to provide it -- the kit will not be made available until after the release of V7.2-6C1. As for the second question... The aio_xxx routines should be assumed to be quite different from the OpenVMS AST routines. (These routines are currently implemented using $qio, $synch, and AST completions, but any assumptions of the internal implementation are perilous at best.) Threads (of any sort) and OpenVMS AST routines must be carefully mixed. There are stringent restrictions on what an application can do within an AST routine executing within a multithreaded process. If the application is calling routines other than (most) system services, or writing longword or quadword-aligned data cells, the routine should likely be translated into a thread. (Many APIs are either AST-safe or thread-safe; most are not both AST- and thread-safe, and -- in a multithreaded process -- the calls that claim to be thread-safe are likely not AST-safe. The OpenVMS Wizard is aware of one OpenVMS system service -- sys$mount -- that is known to be not thread-safe.) Upcalls use ASTs, meaning you must have ASTs enabled in order to timeslice between threads. From the perspective of the OpenVMS executive, upcalls and thread time-slicing are implemented via ASTs -- these ASTs are refer to here as "system ASTs". Also from the perspective of OpenVMS, "application ASTs" are not administered by the executive -- rather, they are handed off to the threads library via an upcall (which happens to be a "system AST"). The threads library then causes the initial thread to begin executing the application AST, but the AST environment is not what OpenVMS would consider AST mode -- the threads library simulates the AST. (The threads library does not set the USER bit in the ASTSR field of the PHD.) That said, the "application AST" will behave very similarly to the behaviour of a hardware AST within a non-threaded application. The threads library emulation underlying the "application AST" extends to support of application calls to AST-related routines including lib$ast_in_prog, $getjpi, $setast, etc. (With upcalls enabled, the application can freely use and alter the "application AST" state, short of making direct PALcode calls.) An additional complicating factor involves the two modes for threaded applications. If the application has upcalls disabled, then threads library has no way to participate in AST delivery. In this senario, time-slicing involves a timer AST and thus if the application disables AST delivery, time-slicing will not function. Nor, for that matter, will other aspects of the threads library function when upcalls are disabled and when ASTs are disabled. There is currently no mechanism to target an AST at a particular thread, as all ASTs run in the initial thread when upcalls are enabled. (There has been some consideration given to targeting an AST back to the thread that generated it, but that support is not available.) With upcalls disabled, the ASTs can run in any thread. Specifically, with upcalls disabled the ASTs will run in whichever thread was executing when the AST became pending. While event flag operation works the same in all situations -- with threading or not, and with upcalls enabled or disabled. With upcalls disabled, if a thread blocks on an event flag, it blocks the entire process until the thread is pre-empted (eg: at the end of its execution quantum). This also implies that threads that are not currently executing will not notice an event flag state transition until they are scheduled and resume execution. Furthermore, if the event flag of interest is set and then cleared, a ready thread may not notice. (Accordingly, use of IOSBs is strongly recommended.) With upcalls enabled, a thread which blocks on a local event flag is immediately removed from scheduling contention -- the result of a synchronous upcall -- and another thread is scheduled and run. When the local event flag becomes set, the threads library receives an upcall via a "system AST" and schedules all threads blocked for that local event flag. If there are IOSBs specified -- as there should be -- the threads library will schedule the threads only when the IOSB has been written. With upcalls and kernel threading enabled, more than one thread can be active at a time (and can operate across multiple processors in an SMP system), but only one AST can be active at a time. You might well see a thread and an AST active in parallel. Threaded applications freely assume that wait states are permitted and not affect other threads, while AST routines generally do not and should not include waits. AST and interrupt routines cannot access a thread mutex, nor can AST or interrupt code call most of the thread routines. With upcalls, AST routines do not block threads running on other processors. (Conversely, with upcalls disabled, threads are not running in parallel on multiple processors.) With upcalls enabled, any thread can call $setast and can enable or disable ASTs across all threads. If a thread disables AST delivery via $setast, then ASTs will not be delivered while that thread is running. With upcalls enabled, the AST delivery status (enabled or disabled) is maintained on a per-thread bases, and ASTs which are not directed to a particular thread (eg: all "application ASTs", at present) will not be delivered to the process as long as any non-terminated thread has ASTs delivery disabled; with upcalls disabled, the AST delivery state is context-switched along with the rest of the thread context. (eg: If a thread had AST delivery enabled when it last ran, then AST delivery will be enabled when it next runs, regardless of the AST delivery state from the previous thread.) AST re-entrancy is a subset of thread re-entrancy -- a routine that is AST re-entrant may not be thread re-entrant. (Why? AST routines can implicitly assume that only one AST routine is active at a time.) That a routine is or is not AST-safe does not imply it is or is not thread-safe. Two terms apply here: "thread-safe", and "thread-reentrant". A thread-safe routine refers simply to the routine being safe to call in a multi-threaded environment -- that is, the function will operate correctly, without access violations or memory corruptions, when called simultaneously or concurrently across multiple threads. (How the thread might achieve this is unspecified.) One of the most typical ways to make a function thread-safe is to place synchronization within the routine to ensure that only one thread can execute the critical code within the routine at one time. The second term, "thread-reentrant", refers to the subset of thread-safe functions which operate correctly without serializing access to their operation by blocking concurrent callers. For instance, lib$get_vm is re-entrant, because it uses atomic operations to manage the look-aside lists and thus multiple threads can allocate memory simultaneously. Similar terminology applies to ASTs: functions can be "AST-safe" or "AST-reentrant". The typical way to make a function AST-safe is to disable ASTs inside the function. This works from within an AST routine -- this call is possible even within an AST routine, though obviously unnecessary -- and it works from the main-line code. With ASTs disabled, the function is serialized. As with a thread-reentrant routine, an AST-reentrant function is one that works properly when called by both main-line and AST code -- without blocking ASTs. Again, lib$get_vm is AST-reentrant because it uses atomic operations. A problem can arise when a function which is not re0entrant wants to be both thread-safe and AST-safe. It is straightfoward enough for such a function to disable AST delivery, since that can be done for both the main-line caller and for ASTs. However, the function cannot use an execution-blocking serialization, such as mutex, to control access to the core of the routine because once AST execution has begun, it cannot be blocked without risking a deadlock. Thus, APIs are forced to choose either thread-safety or AST-safety if they cannot be full-reentrant. If the routine is thread-safe, then it cannot be called in an AST. A routine that is AST-safe is generally either not thread-safe or the routine is fully-reentrant. Simple thread-reentrancy of an API does not imply that the API is also AST-reentrant. One of the techniques frequently employed to make a routine thread-reentrant is to use per-thread storage to allocate what would otherwise be global or static variables. Using this technique, no call in one thread will conflict with a call in any other thread. However, a call from an AST would be executing in the context of some thread; the call would conflict with a concurrent call already in progress in the same thread. If you must use ASTs and threads, you will want to perform the absolute minimum processing within the AST routines, passing off all processing to threads via application-specific work request packets and interlocked queues or other re-entrant technique. The OpenVMS Wizard recommends using great care -- carefully avoid the causes of deadlocks and of data corruptions, as outlined above -- when mixing threads and ASTs within the same application image. Related topics include (2790), (4647), (6099), and (6984).
|