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

The paradigm of acquiring DSSLocks and CSSLocks AFTER fetching the DSS or CSS under a database/collection level lock doesn't work in a lock-free read world

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Duplicate
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • Sharding EMEA

    Description

      DatabaseShardingState and CollectionShardingState use DSSLock and CSSLock mutex RAII types that can only be accessed AFTER the DSS or CSS is fetched. A collection or database level-lock currently protects the DSS::get() and CSS::get() methods. We will not have coll and db locks in the not too distant future, so these expectations should change. Either DSS and CSS should always be safe to access without lock or mutex – the current implementation is, but not officially –, or the DSSLock and CSSLock concepts need to work somehow before fetching the DSS or CSS. (currently the DSS/CSSLock types lock the mutex IN the DSS/CSS).

      We already bypass locking requirements via special DSS/CSS::getSharedForLockFreeReads() getter functions, currently only used by lock-free read supporting operations (find,getMore,count,distinct,mapReduce).

      Attachments

        Activity

          People

            backlog-server-sharding-emea [DO NOT USE] Backlog - Sharding EMEA
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: