3 ms·

I'll go into more details in part two, but part of the problem would have reliably disappeared if I had been running a single-core CPU. Locks are hard.

raattgift 8y ago
> Locks are hard. Yes, especially when the OS does nothing to help a backing-off contender acquire a resource that is greedily dropped and contended by another thread. > I'll go into more details in part two Great! In anticipation of that, I have a couple questions: > but part of the problem would have reliably disappeared if I had been running a single-core CPU Single-core or single-thread? Does the atomic instruction switch to the other HyperThread generally? Do you see the same symptoms if you have a sufficient number of other unrelated CPU-intensive threads trying to run that the OS will want to deschedule the aggressive contender thread(s) from time to time? The ways to deal with this that come to mind are the aggressive contender thread(s) sleeping from time to time, or yielding in hopes the decision about waking up the thread recovers some fairness lost by the decision about which lock waiter win. Perhaps one could just put the lock's cache line on as equal a NUMA footing as it can (a flush, for instance) so the aggressive contender has a chance to lose a race. However, having to reason about cache coherency protocols (differing from vendor to vendor and even same-vendor model to model) seems like a huge headache that anyone would want to avoid if possible. Is a fix described in the long crbug discussion?
- brucedawson 8y ago
  On a single-core/single-thread Windows system the problem would be avoided because when the waiting thread is signaled it gets a priority boost. With just a single core this boost means that it gets to run instead of the other thread. With multiple cores it gets to run as well as the other thread. Making the locks fair or occasionally fair would solve this problem, but perhaps cause others. I think that an appropriate CPU-saturating background task might have made my machine more responsive, which is deliciously weird.

raattgift 8y ago

> Locks are hard. Yes, especially when the OS does nothing to help a backing-off contender acquire a resource that is greedily dropped and contended by another thread. > I'll go into more details in part two Great! In anticipation of that, I have a couple questions: > but part of the problem would have reliably disappeared if I had been running a single-core CPU Single-core or single-thread? Does the atomic instruction switch to the other HyperThread generally? Do you see the same symptoms if you have a sufficient number of other unrelated CPU-intensive threads trying to run that the OS will want to deschedule the aggressive contender thread(s) from time to time? The ways to deal with this that come to mind are the aggressive contender thread(s) sleeping from time to time, or yielding in hopes the decision about waking up the thread recovers some fairness lost by the decision about which lock waiter win. Perhaps one could just put the lock's cache line on as equal a NUMA footing as it can (a flush, for instance) so the aggressive contender has a chance to lose a race. However, having to reason about cache coherency protocols (differing from vendor to vendor and even same-vendor model to model) seems like a huge headache that anyone would want to avoid if possible. Is a fix described in the long crbug discussion?

brucedawson 8y ago
On a single-core/single-thread Windows system the problem would be avoided because when the waiting thread is signaled it gets a priority boost. With just a single core this boost means that it gets to run instead of the other thread. With multiple cores it gets to run as well as the other thread. Making the locks fair or occasionally fair would solve this problem, but perhaps cause others. I think that an appropriate CPU-saturating background task might have made my machine more responsive, which is deliciously weird.