We noticed an issue that can be reproduced in Gaffer by removing the line tile->cachedTile->Object::hash(); from Display::channelData() and running InteractiveArnoldRenderPerformanceTest.testPerfWithBlur with GAFFER_HASHCACHE_MODE set to Checked. The validator reports hashes varying when they shouldn't, which John hypothesizes is due to the way that SharedDataHolder uses a non-threadsafe approach with the hashValid variable handling multiple accesses to the hash. We don't have hard evidence of this, but the fact that precomputing the hashes while holding a lock fixes it, strongly suggests this hypothesis is correct.
We should create a test case that demonstrates incorrect hashing behaviour under heavy thread load, introduce a spinlock to fix it properly, and then make sure that this doesn't impact overall performance too much of tools that rely on SharedDataHolder, like Gaffer.
We noticed an issue that can be reproduced in Gaffer by removing the line
tile->cachedTile->Object::hash();from Display::channelData() and running InteractiveArnoldRenderPerformanceTest.testPerfWithBlur with GAFFER_HASHCACHE_MODE set to Checked. The validator reports hashes varying when they shouldn't, which John hypothesizes is due to the way that SharedDataHolder uses a non-threadsafe approach with the hashValid variable handling multiple accesses to the hash. We don't have hard evidence of this, but the fact that precomputing the hashes while holding a lock fixes it, strongly suggests this hypothesis is correct.We should create a test case that demonstrates incorrect hashing behaviour under heavy thread load, introduce a spinlock to fix it properly, and then make sure that this doesn't impact overall performance too much of tools that rely on SharedDataHolder, like Gaffer.