Delete iterator in replication_test

[igorcanadi]

No description provided.

[danielin917]

Not sure what the difference is here could you give me some context?

[igorcanadi]

They are equivalent, but GetReferencedSuperVersion() is meant to (and optimized to) be called outside of the lock. By adding a mutex to GetSuperSnapshots() (oops) it caused a deadlock :)

[igorcanadi]

It's using quite an interesting technique:

rocksdb-cloud/db/column_family.cc

Lines 1260 to 1277 in 43810fe

	// The SuperVersion is cached in thread local storage to avoid acquiring
	// mutex when SuperVersion does not change since the last use. When a new
	// SuperVersion is installed, the compaction or flush thread cleans up
	// cached SuperVersion in all existing thread local storage. To avoid
	// acquiring mutex for this operation, we use atomic Swap() on the thread
	// local pointer to guarantee exclusive access. If the thread local pointer
	// is being used while a new SuperVersion is installed, the cached
	// SuperVersion can become stale. In that case, the background thread would
	// have swapped in kSVObsolete. We re-check the value at when returning
	// SuperVersion back to thread local, with an atomic compare and swap.
	// The superversion will need to be released if detected to be stale.
	void* ptr = local_sv_->Swap(SuperVersion::kSVInUse);
	// Invariant:
	// (1) Scrape (always) installs kSVObsolete in ThreadLocal storage
	// (2) the Swap above (always) installs kSVInUse, ThreadLocal storage
	// should only keep kSVInUse before ReturnThreadLocalSuperVersion call
	// (if no Scrape happens).
	assert(ptr != SuperVersion::kSVInUse);

[danielin917]

Will have to read more outside the function but definitely interesting. Not quite clear to me how thread local super versions get cleaned after a swap since local_sv becomes obsolete (dump thread does it? but then wouldn't that mess up the currently used sv for the thread?)