5 ms·
False sharing perhaps? At least that is my shoot-from-the-hip response. https://stackoverflow.com/questions/22766191/what-is-false-sharing-how-to-reproduce-avo
by lordnacho 3y ago
False sharing perhaps? At least that is my shoot-from-the-hip response.
https://stackoverflow.com/questions/22766191/what-is-false-sharing-how-to-reproduce-avoid-it https://stackoverflow.com/questions/22766191/what-is-false-s...
- 4gotunameagain 3y agoYeap. The linked cpp ref doc has a nice example: https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size https://en.cppreference.com/w/cpp/thread/hardware_destructiv...
- cafxx 3y agoIn the example you linked it's comparing two threads reading from the same or separate cache lines, no? If so, that's not really the point I was referring to (as the two variables I mentioned as example are accessed by a single thread, not by two threads).
- gpderetta 3y agofalse sharing is the reason for splitting readIdx and writeIdx. But there is no reason to split readIdx and writeIdxCached.
- mananaysiempre 3y agoI don’t get it. Both readIdx_ and writeIdxCached_ are “owned” by the consumer. (That being the point of a “cached” copy.) The producer might read readIdx_ occasionally, whenever we go through the whole buffer, but otherwise only the consumers access these. So why should we avoid putting them on the same cache line?