Coverity analysis defect 152771: Value not atomically updated

XMLWordPrintableJSON

    • Cluster Scalability
    • ALL
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Value not atomically updated

      The result of the update will be determined by the interleaving of thread execution. Non-atomic update of a concurrently shared value
      /src/mongo/db/s/migration_chunk_cloner_source.cpp:673: ATOMICITY 152771 Assuming "lk" is locked since it is unlocked without prior lock in this function.
      /src/mongo/db/s/migration_chunk_cloner_source.cpp:693: ATOMICITY 152771 Assigning data that might be protected by the lock to "execState".
      /src/mongo/db/s/migration_chunk_cloner_source.cpp:698: ATOMICITY 152771 Unlocking "lk._M_device". "execState" might now be unreliable because other threads can now change the data that it depends on.
      /src/mongo/db/s/migration_chunk_cloner_source.cpp:707: ATOMICITY 152771 Unlocking "lk". "execState" might now be unreliable because other threads can now change the data that it depends on.
      /src/mongo/db/s/migration_chunk_cloner_source.cpp:724: ATOMICITY 152771 Locking "this->_mutex" again.
      /src/mongo/db/s/migration_chunk_cloner_source.cpp:725: ATOMICITY 152771 Using an unreliable value of "execState" inside the second locked section. If the data that "execState" depends on was changed by another thread, this use might be incorrect.

            Assignee:
            Kruti Shah
            Reporter:
            Coverity Collector User
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: