4 ms·

Thanks for sharing. Can someone tell me what does this paragraph mean? > Use a lock where you tell the system that you're waiting for the lock, and where the u

Thanks for sharing. Can someone tell me what does this paragraph mean? > Use a lock where you tell the system that you're waiting for the lock, and where the unlocking thread will let you know when it's done, so that the scheduler can actually work with you, instead of (randomly) working against you. I have “implemented” a sleep lock in xv6. Is it what he meant? What does the Linux scheduler “know” about it and will do differently? (Trying to figure out what does “work with you” mean) Thanks in advance.

moregrist 17d ago
In simplest terms: if you don’t tell the kernel that you’re waiting, the scheduler assumes you aren’t and will wake you up and let you spin, to the detriment of other threads that aren’t waiting. If the OS knows that a thread is waiting for a lock, the scheduler will not bother to schedule it until the lock is available. In general, it’s tempting when you’re bound by lock latency to skip the syscall overhead of sleeping. But a lot of the time that’s a code smell that there are other inefficiencies in the system and you should rethink how you’re scheduling work.
rcxdude 16d ago
The basic idea is that a lock should be something the OS is aware of, so that while a thread is blocked on a lock, the scheduler never tries to wake it at all, and when it is unlocked, the scheduler can wake up the thread that's waiting on it immediately. If the scheduler isn't aware of the lock, it'll just try to wake up the thread periodically, often just wasting CPU when it's still blocked or kept asleep when it could be running.
BoingBoomTschak 16d ago
I think he means that if the OS knows about locking, it can manage a list of "waiters" to quickly know which thread to wake (resp. let sleep) once (resp. before) the lock is released. A bit like what classic UNIX does with wchan, but between the kernel and userspace this time. Related: https://rdmsr.github.io/writing/turnstiles/ https://rdmsr.github.io/writing/turnstiles/

moregrist 17d ago

In simplest terms: if you don’t tell the kernel that you’re waiting, the scheduler assumes you aren’t and will wake you up and let you spin, to the detriment of other threads that aren’t waiting. If the OS knows that a thread is waiting for a lock, the scheduler will not bother to schedule it until the lock is available. In general, it’s tempting when you’re bound by lock latency to skip the syscall overhead of sleeping. But a lot of the time that’s a code smell that there are other inefficiencies in the system and you should rethink how you’re scheduling work.

rcxdude 16d ago

The basic idea is that a lock should be something the OS is aware of, so that while a thread is blocked on a lock, the scheduler never tries to wake it at all, and when it is unlocked, the scheduler can wake up the thread that's waiting on it immediately. If the scheduler isn't aware of the lock, it'll just try to wake up the thread periodically, often just wasting CPU when it's still blocked or kept asleep when it could be running.

BoingBoomTschak 16d ago

I think he means that if the OS knows about locking, it can manage a list of "waiters" to quickly know which thread to wake (resp. let sleep) once (resp. before) the lock is released. A bit like what classic UNIX does with wchan, but between the kernel and userspace this time. Related: https://rdmsr.github.io/writing/turnstiles/ https://rdmsr.github.io/writing/turnstiles/