To summarize the comparison between the two, we want busy-waiting if we think we won't be waiting for a long time because it is expensive for the OS to swap the context in and out with the resources. Additionally, we want the busy-waiting if there isn't another thread waiting to be run using the execution resources.
EDITED.
jaguar
If blocking can be potentially more expensive, is it the case that the energy considerations that may cause a programmer to normally choose blocking would also be improved by busy-waiting?
CC
@makingthingsfast Correct me if I am wrong, but I think the slide means the other way around of what you wrote. We prefer busy waiting over blocking when the waiting time is short and when the execution resources are undersubscribed.
makingthingsfast
@CC Yes, you're right! I just edited my post. I mistyped what I had in my notes from class. Thanks for the catch!
PID_1
In the "Processor's resources not needed for other tasks" case, why is it okay to assume that other processes don't need to be making use of those resources?
It is almost certainly the case that the number of threads running background processes greatly oversubscribe the available hardware resources on any machine. Are we just assuming that they do little enough computation to ever matter?
maxdecmeridius
When dealing with something like a critical add, where moving the thread on and off the core is more expensive than busy waiting for that operation to complete, are there compiler optimizations to prevent this less optimal lock from happening?
randomthread
@maxdecmeridius Moving threads on and off the core is the responsibility of the OS. Additionally, even if we are spinning the OS can still context switch to another process/thread as a result of the scheduler. If not being rescheduled during a busy wait is so critical for latency concerns then a real time OS would be more appropriate and would have the mechanisms necessary for maintaining critical latency bounds.
FarmerScrub
@PID_1 In many cases, the majority of background threads are inactive and sleeping. Recall when Kayvon showed us the processes and threads running on his laptop, there were hundreds of threads, but the CPU utilization was in the single digits.
kayvonf
Good discussion everyone. Nice job.
yimmyz
An example relating to my experience in OS: When we were implementing Read/Write locks, it was the most appropriate to use spinlock for mutual exclusion of Read locks (since read requests are not supposed to last long), and to use blockings for mutual exclusion of Write locks (since write requests take much longer).
monkeyking
Real life analogy:
Busy-waiting is like, after I order my dinner, I keep asking the waiter: "is my dinner ready? Is my coffee ready?" until I got my dinner (spin). Then people behind me can order his/her dinner.
Busy-waiting is like, after I order my dinner, I wait outside the queue (blocked). And when I notice that my dinner is ready, I go to the tail of the queue, waiting for getting it (runnable). Then when it is my turn (running), I get my dinner.
So Busy-waiting is suit for two cases:
1.The line behind me is too long so that if I leave the counter I will need to wait for 10 minutes to ask the waiter again. Since the dinner can be ready in 1 minute, it is better to keep asking for 1 minute.
2.The line is empty behind me. Nobody wants to order after me. So I can keep annoying the waiter until I get my dinner.
leis1
Real life analogy2:
Busy-waiting: "are we there yet?","are we there yet?","are we there yet?","are we there yet?"
Blocking: "tell me when we are there"
PandaX
Busy waiting can be preferable than blocking if processor's resources are not needed for other tasks. For example, we are running 4 threads on 4 cores. We really don't need blocking because the processor would not be used by other threads anyway if we reschedule the thread running on it.
To summarize the comparison between the two, we want busy-waiting if we think we won't be waiting for a long time because it is expensive for the OS to swap the context in and out with the resources. Additionally, we want the busy-waiting if there isn't another thread waiting to be run using the execution resources.
EDITED.
If blocking can be potentially more expensive, is it the case that the energy considerations that may cause a programmer to normally choose blocking would also be improved by busy-waiting?
@makingthingsfast Correct me if I am wrong, but I think the slide means the other way around of what you wrote. We prefer busy waiting over blocking when the waiting time is short and when the execution resources are undersubscribed.
@CC Yes, you're right! I just edited my post. I mistyped what I had in my notes from class. Thanks for the catch!
In the "Processor's resources not needed for other tasks" case, why is it okay to assume that other processes don't need to be making use of those resources?
It is almost certainly the case that the number of threads running background processes greatly oversubscribe the available hardware resources on any machine. Are we just assuming that they do little enough computation to ever matter?
When dealing with something like a critical add, where moving the thread on and off the core is more expensive than busy waiting for that operation to complete, are there compiler optimizations to prevent this less optimal lock from happening?
@maxdecmeridius Moving threads on and off the core is the responsibility of the OS. Additionally, even if we are spinning the OS can still context switch to another process/thread as a result of the scheduler. If not being rescheduled during a busy wait is so critical for latency concerns then a real time OS would be more appropriate and would have the mechanisms necessary for maintaining critical latency bounds.
@PID_1 In many cases, the majority of background threads are inactive and sleeping. Recall when Kayvon showed us the processes and threads running on his laptop, there were hundreds of threads, but the CPU utilization was in the single digits.
Good discussion everyone. Nice job.
An example relating to my experience in OS: When we were implementing Read/Write locks, it was the most appropriate to use spinlock for mutual exclusion of Read locks (since read requests are not supposed to last long), and to use blockings for mutual exclusion of Write locks (since write requests take much longer).
Real life analogy:
Busy-waiting is like, after I order my dinner, I keep asking the waiter: "is my dinner ready? Is my coffee ready?" until I got my dinner (spin). Then people behind me can order his/her dinner.
Busy-waiting is like, after I order my dinner, I wait outside the queue (blocked). And when I notice that my dinner is ready, I go to the tail of the queue, waiting for getting it (runnable). Then when it is my turn (running), I get my dinner.
So Busy-waiting is suit for two cases:
1.The line behind me is too long so that if I leave the counter I will need to wait for 10 minutes to ask the waiter again. Since the dinner can be ready in 1 minute, it is better to keep asking for 1 minute.
2.The line is empty behind me. Nobody wants to order after me. So I can keep annoying the waiter until I get my dinner.
Real life analogy2:
Busy-waiting: "are we there yet?","are we there yet?","are we there yet?","are we there yet?"
Blocking: "tell me when we are there"
Busy waiting can be preferable than blocking if processor's resources are not needed for other tasks. For example, we are running 4 threads on 4 cores. We really don't need blocking because the processor would not be used by other threads anyway if we reschedule the thread running on it.