Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-8722

OpCounters::incInsertInWriteLock not thread-safe.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Gone away
    • Affects Version/s: 2.2.3, 2.4.0-rc1
    • Fix Version/s: None
    • Component/s: Concurrency
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      Should be possible to demonstrate by creating a test node with several logical databases, and driving a lot of w=1 inserts to it, scattered across the databases. If you keep track of the number of inserts, you should find that it is greater than what the database reports. It might help to do multi-inserts, it might help to do only single inserts; I'm not sure.

      Show
      Should be possible to demonstrate by creating a test node with several logical databases, and driving a lot of w=1 inserts to it, scattered across the databases. If you keep track of the number of inserts, you should find that it is greater than what the database reports. It might help to do multi-inserts, it might help to do only single inserts; I'm not sure.
    • Sprint:
      Storage 2016-12-12

      Description

      Once upon a time, the _insert counter in the OpCounters class was only ever incremented when the single global writelock was held. In that world, the implementation that uses a non-atomic operation to increment the counter wouldn't lead to lost counts, though it could hypothetically lead to incorrect reads if the _insert counter weren't 4-byte aligned.

      Today, the function is often called without a global lock held (only a per database lock), making these adds lossy.

      It would be wise to fix this, perhaps by consolidating the implementation of AtomicUInt with the AtomicWord<T> or at least the AtomicIntrinsics<T> from mongo/platform/atomic_word.h. This would also allow us to make these counters 64-bit instead of 32-bit, in case we're ever worried about rollover.

        Attachments

          Activity

            People

            Assignee:
            daniel.gottlieb Daniel Gottlieb
            Reporter:
            schwerin Andy Schwerin
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: