Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5395

Fix a bug in the read lock implementation when there is a lot of contention

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Critical - P2 Critical - P2
    • WT10.0.0, 4.3.3, 4.2.4, 4.0.17
    • Affects Version/s: None
    • Component/s: None
    • 8
    • Storage Engines 2020-01-27
    • v4.2, v4.0

      While running Workgen benchmark evict-btree-lookaside.py with a higher number of reader/search threads, we hit an assert in __wt_readlock() with following message:


      WT_CURSOR.search: __wt_readlock, 274: ticket == l->u.s.current && l->u.s.readers_active > 0
      WT_CURSOR.search: __wt_abort, 28: aborting WiredTiger library



      Read/write lock implementation in WiredTiger has a bug where a call for read lock through _wt_readlock() would result in assert. This only happens when there are a large number of readers and writers threads that are competing for the lock. This root cause is a buggy piece of code in implementation of wt_readlock() that results in variable value to overflow beyond the maximum value. This bug has existed since current R/W lock was implemented through WT-3345.  

            haseeb.bokhari@mongodb.com Haseeb Bokhari (Inactive)
            haseeb.bokhari@mongodb.com Haseeb Bokhari (Inactive)
            0 Vote for this issue
            5 Start watching this issue