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

Clarify rules/semantics for Client Lock

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: None

      Description

      Right now, it's tricky from reading the code and comments to figure out exactly what the semantics of the Client Lock are (when does it need to held? what exactly does it protect? etc). After digging into this I arrived at an understanding that:
      1) The thread bound to a client can always read that client's data members/internals without taking the lock
      2) If the thread bound to a client wants to write to data members/internals that might be read by other threads first, it must take the lock first
      3) Other threads (i.e. those unbound to the client) that are reading the client's internals must take the lock before doing so, both to keep those members synchronized and to protect the Client from being destroyed mid-read

      This leaves open the further question: what data members of the client exactly can be read by un-bound threads, and therefore need to be protected by the client lock? Specifically, are there any such data other than the contents of CurOp – historically, only data in the Client's CurOp decoration was legally accessable from other threads, but it's unclear if this is still true.

      We should try and answer this open question, and clarify what we do know at least with a comment in the code. For example, this comment https://github.com/mongodb/mongo/blob/9cf1509ad2664830d37a7a128d43752dcac8556a/src/mongo/db/client.h#L143 describing the Client lock appears to be out of date and is confusing – we should replace it I think with what we've settled on above at least.

      We could also use this ticket to investigate opportunities to use not just comments but code (especially the type system) to see if we could make it clear what could be read by unbound threads and what cannot (and therefore just when the client lock needs to be held)

        Attachments

          Activity

            People

            Assignee:
            backlog-server-servicearch Backlog - Service Architecture
            Reporter:
            george.wangensteen George Wangensteen
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated: