Just curious, is there any case that we actually want an unfair lock?
wcrichto
I could see a potential use case where you have a shared resource that requires mutual exclusion, but each requesting thread should have different priorities. I don't know off hand if such a use case exists, however.
Jing
Maybe it's easy to think a way of adaptively changing the multiplier to prevent starvation. Such as the multiplier being a function of time that the process has already waited for
kayvonf
@meatie. Perhaps one example is a situation where processes had different priorities (in Assignment 4 some requests are worth more points.). Also, in a real-time system I'd prioritize the real-time processes over the non-real-time ones.
Actually, this kind of reminds me of the readers-writer lock. The usual solution prioritizes the writer - the issue is always one of starvation. It seems like an unfair lock with weighting might be an interesting solution, which might help prevent starvation (though, of course, with anything probabilistic, there's always that chance than infinity will become real).
sanchuah
I am curious what are the advantages of this approach over "test-test-set" approach?
lament
@sanchuah Um. What specifically are you wondering about? There are advantages listed on the slide, but with your question you seem to be implying that those are not sufficient. Is there something more specific you would like discussed?
Kapteyn
One reason why there may be higher latency under high contention is that the delay amount may be an overestimation of how long the processor should wait. So it could be the case that the lock is free, but no processor tries to get it because they're all waiting for their delay to be over.
Just curious, is there any case that we actually want an unfair lock?
I could see a potential use case where you have a shared resource that requires mutual exclusion, but each requesting thread should have different priorities. I don't know off hand if such a use case exists, however.
Maybe it's easy to think a way of adaptively changing the multiplier to prevent starvation. Such as the multiplier being a function of time that the process has already waited for
@meatie. Perhaps one example is a situation where processes had different priorities (in Assignment 4 some requests are worth more points.). Also, in a real-time system I'd prioritize the real-time processes over the non-real-time ones.
http://en.wikipedia.org/wiki/Real-time_operating_system
Actually, this kind of reminds me of the readers-writer lock. The usual solution prioritizes the writer - the issue is always one of starvation. It seems like an unfair lock with weighting might be an interesting solution, which might help prevent starvation (though, of course, with anything probabilistic, there's always that chance than infinity will become real).
I am curious what are the advantages of this approach over "test-test-set" approach?
@sanchuah Um. What specifically are you wondering about? There are advantages listed on the slide, but with your question you seem to be implying that those are not sufficient. Is there something more specific you would like discussed?
One reason why there may be higher latency under high contention is that the delay amount may be an overestimation of how long the processor should wait. So it could be the case that the lock is free, but no processor tries to get it because they're all waiting for their delay to be over.