PROBLEM:  (MCPM31P0Q/QAR 60741)    (Patch ID: OSF435-425407)
********
This patch is a fix to libtli/libxti to correctly handle a continuation
data message still on the stream head.

PROBLEM:  (SSRT0546U, SSRT0542U)    (Patch ID: OSF435-001)
********
A potential security vulnerability has been discovered, where under
certain circumstances, system integrity may be compromised. This may
be in the form of improper file or privilege management. Digital has
corrected this potential vulnerability.

PROBLEM:  (QAR 58658)    (Patch ID: OSF435-024)
********
Thread-aware debuggers (particularly TotalView) that make extensive use of
the libpthreaddebug.so HOLD/UNHOLD mechanisms for breakpoints may expose a
race condition that can lead to a SIGSEGV within the user-mode thread
scheduling code. This can lead to a "quiet" process exit: a core file is
generated, but no message appears, and the proc filesystem reports a normal
termination to the debugger.

Other HOLD-related races can result in the process being debugged ignoring the
debugger's HOLD request, or in corrupting the saved state of a thread.

PROBLEM:  (QAR 58658)    (Patch ID: OSF435-024)
********
DECthreads can optimize the performance of some common thread operations for
programs compiled using DEC C, by utilizing the DEC C asm() syntax to include
machine instructions.  DECthreads does not use asm() syntax under other
compilers, but nevertheless with the gcc compiler asm() syntax.

PROBLEM:  (QAR 60358)    (Patch ID: OSF435-024)
********
This patch corrects a problem related to "call system" fortran statement.
A fortran program, which is compiled with -omp switch (openMP), hangs on a
"call system" fortran statement in a fortran program.

PROBLEM:  (QAR 66683)    (Patch ID: OSF435-129)
********
DECthreads was not properly changing the priority of a suspended thread,
adversely effecting Java programs.  The routine pthread_setschedparam() was
not properly handling threads that are suspended.

PROBLEM:  (QAR 66254)    (Patch ID: OSF435-129)
********
The routines, pthread_mutex_trylock() and tis_mutex_trylock(), as coded in the
libpthread and libc, respectively, can cause uncontested lock operations to
take the "slow path" when they would not have to otherwise. This shows a
significant performance problem for the malloc mutex under heavy load.

PROBLEM:  (QAR 60355)    (Patch ID: OSF435-129)
********
A bug in DECthreads affected the preemption of realtime SCS threads. In one
instance a low priority SCS thread would run before a higher priority SCS
threads.  Another problem occurred when one SCS thread joined with another
SCS thread, by calling the pthread_join() function before the "target" SCS
thread had terminated. In that situation, the joiner thread may never be
unblocked from the wait.

PROBLEM:  (CLD HPAQ81B6C)    (Patch ID: OSF435-129)
********
Multithreaded applications can experience performance problems if they are
run on multi-cpu systems and make heavy use of any of the functions on the
malloc(3) manpage.  This includes C++ applications making heavy use of "new"
and "delete".  The primary fix for this problem exists within libc, however
DECthreads contained inefficiencies in the mutex logic code which made the
problem worse.

PROBLEM:  (HPAQ81B6C)    (Patch ID: OSF435-130)
********
Multithreaded applications can experience performance problems if they are
run on multiCPU systems and make heavy use of any of the functions on the
malloc(3) manpage (including C++ applications making heavy use of "new" and
"delete").  On profiling these applications, they will be seen to be spending
a large percentage of their CPU time in two pthreads functions
(pthread_mutex_block and pthread_mutex_unblock) which are called from the
malloc family of functions.  The problem becomes worse under the following
conditions: the number of threads increases, the number of CPUs increases,
or more calls are made to the malloc functions.

PROBLEM:        ( QAR 69251)    (Patch ID: OSF435-425582)
********
With version 52, Ladebug has begun to employ a "user thread hold" mechanism.
This patch fixes problems in DECthreads, when using this mechanism, which
might result in missed breakpoints and watchpoints, as well as causing
application hangs.

PROBLEM:        ( CLD HPAQ21HQ9)    (Patch ID: OSF435-425582)
********
This patch fixes a DECthreads problem in which an invalid scheduling priority
bugcheck in encountered.  This is caused by incorrect referencing of
scheduling data structures inside DECthreads.

PROBLEM:        ( QAR 69364)    (Patch ID: OSF435-425582)
********
This patch fixes a problem in DECthreads manager thread logic.  The manager
thread is being scheduled to run in response to a system event (nxm action,
timer queue expiration, etc.) but is not recognizing the event as the reason
it was scheduled to run.  The manager thread then goes back to sleep, only to
wake up again in response to the still unserviced system event.  An infinite
loop results.