The problem with this approach is that it is not fair in the sense that the first person who tries to acquire the lock will wait longer to try again. Also, I think integer overflow is another problem.
What is delay in this case? If it is busy-spinning then it suffers all the problem busy-waiting has. It is certainly not a thread_yield since a lock cannot tell the scheduler to schedule it after some time.
jrgallag
@pavelkang, I'm not sure what you mean by "a lock cannot tell the scheduler to schedule it after some time" - I think you're referring to how if we descheduled our thread, no one would resume us. We don't need to deschedule indefinitely though, most operating systems support a sleep() function, which will deschedule our thread for a certain number of clocks and then resume it.
BensonQiu
@pavelkang: To solve the integer overflow issue, we could clamp the maximum delay. I think it would make sense to do this anyway, since we don't want threads to have too long of a delay (otherwise, latency under contention would be very high).
pavelkang
@jrgallag I was trying to say that a user program can't tell the scheduler what to do, but you are right, sleep is the way to do that
Renegade
To answer the question in the slide: when uncontended, thread can grab the lock at first try and thus no delay() involves, i.e. the same latency as t-s; when contended, after several failed attempts during other thread holding the lock, the "amount" would increase exponentially, so it has to wait unnecessarily long time even for a free lock.
The problem with this approach is that it is not fair in the sense that the first person who tries to acquire the lock will wait longer to try again. Also, I think integer overflow is another problem.
What is delay in this case? If it is busy-spinning then it suffers all the problem busy-waiting has. It is certainly not a thread_yield since a lock cannot tell the scheduler to schedule it after some time.
@pavelkang, I'm not sure what you mean by "a lock cannot tell the scheduler to schedule it after some time" - I think you're referring to how if we descheduled our thread, no one would resume us. We don't need to deschedule indefinitely though, most operating systems support a sleep() function, which will deschedule our thread for a certain number of clocks and then resume it.
@pavelkang: To solve the integer overflow issue, we could clamp the maximum delay. I think it would make sense to do this anyway, since we don't want threads to have too long of a delay (otherwise, latency under contention would be very high).
@jrgallag I was trying to say that a user program can't tell the scheduler what to do, but you are right, sleep is the way to do that
To answer the question in the slide: when uncontended, thread can grab the lock at first try and thus no delay() involves, i.e. the same latency as t-s; when contended, after several failed attempts during other thread holding the lock, the "amount" would increase exponentially, so it has to wait unnecessarily long time even for a free lock.