fixes #5701 The assert half correct, half over-active. When the manager's...

fixes #5701 The assert half correct, half over-active. When the manager's mutex is held it is okay to transition an existing locktree's reference count from 0 to 1. If the lock isn't held, it's a race, since one thread could be destroying the zero-ref count locktree when you're incrementing the count. The failure occurred with the manager's mutx held (so the assert was overactive) and it's a layering-pain to assert that the manager's mutex is held otherwise, so just get rid of it.


git-svn-id: file:///svn/toku/tokudb@50297 c7de825b-a66e-492c-adef-691d508d4ae1

locktree/manager.cc

@@ -129,8 +129,11 @@ void locktree::manager::reference_lt(locktree *lt) {
     //
     // the caller can do this by already having an lt
     // reference or by holding the manager mutex.
-    uint32_t old_reference_count = toku_sync_fetch_and_add(&lt->m_reference_count, 1);
-    invariant(old_reference_count > 0);
+    //
+    // if the manager's mutex is held, it is ok for the
+    // reference count to transition from 0 to 1 (no race),
+    // since we're serialized with other opens and closes.
+    toku_sync_fetch_and_add(&lt->m_reference_count, 1);
 }
 
 void locktree::manager::release_lt(locktree *lt) {