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

    • Type: Icon: Improvement Improvement
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Sharding EMEA

      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).

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

              Created:
              Updated:
              Resolved: