HP OpenVMS Systems

POSIX Threads?

» close window

The Question is:

 
RE: PTHREADS / AST's
 
Dear Wizard,
 
 
    POSIX.4 (1003.1b) introduced, amongst other things, an asynchronous
    i/o specification. However, one author suggests that "it takes a
    long time to setup the dispatch out to a user signal handler. It
    then takes a while to execute the handler (OBVIOUSLY), and it takes
    quite a while to clean up after the handler before returning to the
    main-line code"
 
 
    Q1 - Since OpenVMS has ALWAYS supported asynchronous i/o, is it a
         fair assumption that setting up and dispatching to an AST, and
         later returning from an AST is not considered expensive ?
         (I know quantify expensive)
 
 
    On OpenVMS, at least prior to Pthreads, the typical (IMHO) AST
    derived server, simply dispatches to the AST, where it enqueues
    the received data to the main-line code via _insqti.
 
    With the advent of Pthreads / Kernel Threads, some programmers
    will advocate the use of a Thread for each client connection.
 
    Q2 - Has the wizard (or engineering) any comment on the relative
         performance differences between an AST derived Server, and
         a Pthreads based Server.
 
         For example, take a single (Alpha 7.2-1) cpu machine, which
         is not starved of memory and/or quotas, where the only design
         criteria is SPEED (i.e. ignore portability, as well as any
         discussion about complexity of code). Do the wizard(s) consider
         it more efficient (or have experience) to context switch
         between 1000 Threads or to dispatch out to the AST's, which
         then feed the main-line code, or perhaps a combination of both.
 
    Q3 - As above, but on a SMP machine.
 
    Q4 - When mixing Pthreads with AST's ...
         should you compile /REENTRANCY=AST or
                            /REENTRANCY=MULTITHREAD
 
    Q5 - Are there any (known) plans to support some or all of the
         POSIX.4 (1003.1b) API calls under OpenVMS ? If so, when ?
         If not, why not ?
 
   The  DECTHREADS manuel states
       >> AST routines should already be performing only atomic operations,
       >> since thread synchronization is not available to code executing
       >> at AST level.
    Q6 - Are there any plans to lift this limitation.
 
    pthread_cond_signal_int_np is one pthread routine callable from an AST
    Q7 - Any plans to support more Pthread functions from within an AST
 
    Q8 - Is it Engineering's intention to provide Pthread support for
         all the lib$ routines ?
 
    Q8 - Another Posix.4b (1003.1d) defines a new delivery mechanism,
         SIGEV_THREAD, which causes a function (thread) to be called
         upon completion of a asynchronous i/o event ... any such
         planned support in OpenVMS
 
 
TIA
 
 
fred
 
 

The Answer is :

 
  Re: performance?
 
  Try it.
 
  re: mixing ASTs and threads?
 
  Mixing ASTs and threads is not something the OpenVMS Wizard
  recommends.
 
  re: Adding POSIX API calls?
 
  Yes, the inclusion of various calls into OpenVMS continues.
  (Discussions of "when" and release scheduling in general tend to
  be beyond the purview of the OpenVMS Wizard.)
 
  re: making the OpenVMS RTLs thread-safe?
 
  The OpenVMS Wizard is not immediately familiar with any plans
  to make all of the various OpenVMS RTLs thread-safe.
 

  

     

     
answer written or last revised on ( 7-DEC-1999 )
     
» close window