Why would we use this kind of an implementation? It seems that the exponential back-off will cause some threads to almost never be able to get a lock because each time they attempt to get the lock and fail, they have to wait twice as long to try again.
bpr
@kevinle1, usually when the back-off exceeds the cost of context switching, the thread will yield rather than increasing the back-off further. Or the lock may saturate at some maximum delay. However, you are right that exponential back-off can be severely unfair to some threads.
hanzhoul
Under uncontented situation, is test-and-set with back off faster than test-and-test-and-set?
bpr
@hanzhoul, yes, without contention, you want to execute the test-and-set as soon as possible. If you have to test first, then that requires an additional coherence request.
Why would we use this kind of an implementation? It seems that the exponential back-off will cause some threads to almost never be able to get a lock because each time they attempt to get the lock and fail, they have to wait twice as long to try again.
@kevinle1, usually when the back-off exceeds the cost of context switching, the thread will yield rather than increasing the back-off further. Or the lock may saturate at some maximum delay. However, you are right that exponential back-off can be severely unfair to some threads.
Under uncontented situation, is test-and-set with back off faster than test-and-test-and-set?
@hanzhoul, yes, without contention, you want to execute the test-and-set as soon as possible. If you have to test first, then that requires an additional coherence request.