Conference orarep::nomahs::rdb_60

        2.5.55 Queue Operations Were Not AST Safe

              Oracle Rdb uses queue structures throughout the product.
              It has been found that many of the queue operations in the
              Alpha version of the product were not AST safe and some
              of the queue operations on the VAX version of the product
              were not AST safe. There was a very small window of time
              where main line code could start a queue operation and
              get interrupted by an AST routine which would operate on
              the queue. When this occurred, the integrity of the que is
              damaged and resulted in problems that were random and very
              hard to reproduce. Though Rdb uses queues widely throughout
              the product, there were not many areas of the code where a
              queue operation would be interrupted by an AST routine and
              where the AST routine would operate on the same queue as
              the main line code.

              Fortunately, we were able to work with a test case which
              would eventually reproduce one of the problems caused by
              this problem on a somewhat consistent basis. The symptom
              of the reproducible case we worked with was similar to the
              following:

        Node: EWB715          DEC Rdb V6.1-02 Performance Monitor   20-MAR-1996 13:17:32
        Rate: 3.00 Seconds               Stall Messages             Elapsed: 16:53:50.23
        Page: 1 of 1  DIR_SYS_DB2ROOT:[DATABASE.SHIEN.WORK]NFS1$DBF_WORK.RDBMode: Online
        --------------------------------------------------------------------------------
        Process.ID Since......   Stall.reason............................. Lock.ID.
        2BA0043D:1 20:25:56.83 - waiting for page 1:28341 (PR)             64000053
        2BA0043E:1 20:25:56.83 - writing RUJ file block 2160

        Resource: page 28341

              ProcessID Process Name        Lock ID   System ID Requested Granted
              --------- ---------------     --------- --------- --------- -------
    Blocker:  2BA0043E  BATCH_443......     4800113B  0001005D  PW        PW
    Waiting:  2BA0043D  BATCH_442......     64000053  0001005D  PR        NL

          Notice that BATCH_442 (PID 2BA0043D) is waiting for a lock
          on page 28341 which is currently held in PW by BATCH_443
          (PID 2BA0043E). From the Stall Messages screen in RMU/SHOW
          STATISTICS, we see that BATCH_443 is stalled waiting to
          flush to the RUJ file. Notice also that the timestamps of
          the stalls for both processes are identical. In this case,
          when BATCH_442 stalled for the page lock, a blocking AST
          (BLAST) was delivered to BATCH_443. Unfortunately, BATCH_
          443 was starting a queue operation at the time, and the
          BLAST happened to also operate on that queue. The queue
          subsequently became corrupt causing BATCH_443 to hang
          forever which in turn caused BATCH_442 to hang since it
          was waiting for BATCH_443 to demote it's lock on the page.
          Obviously, this was a rare occurrence since the BLAST had
          to be delivered within a 1 instruction window of time.

          After putting in the code changes to make sure the queue
          operations were AST safe, several problems that have been
          reported and reproduced with our internal testing have
          been resolved. The following bugcheck offsets represent
          bugchecks that no longer occurred in our internal V6.1
          testing after the fix was implemented:

               LCKCCH$WEAKEN_LEVEL_1 + 000000E4
               LCK$LOCK + 00000134
               LCKCCH$LOCK_DUPLEX + 00000554
               LCKCCH$LOCK_DUPLEX + 00000684
               LCKCCH$LOCK_DUPLEX_HARD + 0000085C
               LCKCCH$COMMIT_SUBTREE + 00000050
               LCKCCH$COMMIT_SUBTREE + 0000019C
               LCKCCH$LOCK_SIMPLEX_HARD + 00000450

          This problem has been corrected in Oracle Rdb Version 6.0A
          ECO 5.