Unexpected behavior on unit test with assign/erase/assign

[brandon-kohn]

Apologies if this turns out to be due to my own mishandling of the library.

I've written a test in some of my own code to see what container I should use for a concurrent hash map. The test is as follow (adapted to junction):

template <typename Pool>
void bash_junction_map(Pool& pool, const char* name)
{
	using namespace ::testing;
	using namespace stk;

	junction::ConcurrentMap_Leapfrog<int, int> m;

	auto nItems = 10000;
	for (auto i = 2; i < nItems + 2; ++i)
	{
		m.assign(i, i * 10);
	}

	using future_t = typename Pool::template future<void>;
	std::vector<future_t> fs;
	fs.reserve(100000);
	{
		GEOMETRIX_MEASURE_SCOPE_TIME(name);
		for (unsigned i = 2; i < 100000 + 2; ++i) {
			fs.emplace_back(pool.send([&m, i]() -> void
			{
				for (int q = 0; q < nsubwork; ++q)
				{
					m.assign(i, i * 20);
					m.erase(i);
					m.assign(i, i * 20);
				}
			}));
		}
		boost::for_each(fs, [](const future_t& f) { f.wait(); });
	}

	for (auto i = 2; i < 100000 + 2; ++i)
	{
		auto r = m.find(i);
		EXPECT_EQ(i * 20, r.getValue());
	}
}

My understanding is that an assign operation followed by an erase and then another assign ought to essentially cancel each other out. However, I'm getting spurious failures with junction:

Note: Google Test filter = timing.work_stealing_thread_pool_moodycamel_concurrentQ_bash_junction
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from timing
[ RUN      ] timing.work_stealing_thread_pool_moodycamel_concurrentQ_bash_junction
G:\Projects\simulation_suite\test\fiber_timing_tests.cpp(150): error: Expected equality of these values:
  i * 20
    Which is: 1032520
  r.getValue()
    Which is: 0
G:\Projects\simulation_suite\test\fiber_timing_tests.cpp(150): error: Expected equality of these values:
  i * 20
    Which is: 540200
  r.getValue()
    Which is: 0
G:\Projects\simulation_suite\test\fiber_timing_tests.cpp(150): error: Expected equality of these values:
  i * 20
    Which is: 1032520
  r.getValue()
    Which is: 0
[  FAILED  ] timing.work_stealing_thread_pool_moodycamel_concurrentQ_bash_junction (35310 ms)
[----------] 1 test from timing (35311 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (35313 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] timing.work_stealing_thread_pool_moodycamel_concurrentQ_bash_junction

 1 FAILED TEST
Press any key to continue . . .

Are my expectations incorrect?

[preshing]

Hmm, that's interesting. Could be a bug. Could you try ConcurrentMap_Linear and ConcurrentMap_Grampa?

[brandon-kohn]

Sure. I've tried with both of those as well now, and it happens with all 3. It seems that Grampa is the worst of all.. many failures. Linear seems to have a lower frequency of these than Leapfrog. I probably shouldn't make such statements about the frequency between Linear and Leapfrog.. I don't have enough samples to really say. The Grampa was significant in that there were over a dozen failures whereas the others would have 0-3 over 200 runs.

[preshing]

It was indeed a bug in the maps. I submitted a fix. Thanks a lot for finding this repro case! Feel free to reopen if you have further issues.

[preshing]

I also noticed you don't seem to be calling junction::DefaultQSBR.update() periodically from each thread that manipulates the map. You might want to do so, or else you will leak memory as mentioned here. Sorry the documentation isn't better.