Busy-waiting is bad because execution resources are being used to run the while loop when they could have been used to run other threads (such as the one we are waiting for to release a resource to make the condition X true).
yulunt
Although busy-waiting wastes the CPU time, it has advantages in some cases. For example, if the cost of context switch is higher than running the while loop or the computation in the locked block is simple, the wasted time is neglectable. Another situation is to deal with priority inversion issues. If threads have different priorities, busy-wait may prevent threads with higher priority from suffering more priority inversion. This is important especially in real-time system.
rc0303
Busy waiting can also be beneficial in multinode systems without shared memory, if a node only has one thread running on it and is waiting for computation on another node to complete.
nemo
@rc303 To add to that, even on a single node, if the total number of threads running is same as the number of available cores, we might as well busy wait!
life
@nemo, I think when the number of threads is same as the number of available execution contexts, busy waiting is still ok?
firebb
@life, for multiple execution contexts on a single core, busy waiting of one thread might hurt the performance of another thread actually holding the lock.
nemo
@life Why do you think so? The thread is running (busy waiting) and other runnable threads (in execution context) could do useful work using those resources.
muchanon
@firebb Why would it hurt the performance if the thread holding the lock if the other thread is just spinning waiting for the lock? Shouldn't the one with the lock be able to execute without being affected by the fact that another thread is waiting for the lock?
lya
@muchanon For busy waiting, multiple execution contexts will hurt the lock since the waiting threads will still be scheduled to run on the core even if they are not able to make any progress. On the contrary, in blocking synchronization, waiting threads will be de-scheduled, so that they will not affect the thread that is holding the lock.
shhhh
@lya Just to make sure, are you referring to the case that a thread holding a lock requests memory and the context switches to another thread on the same core to hide latency, but that thread never ends because it is busy waiting for a lock acquired by the first thread?
anonymous
I think whether "busy-waiting" is bad or not depends on the property of the "critical section". In Linux kernel programming, there's a similar question - When to use "mutex" and when to use "spin-lock"?
I find a cool discussion in StackOverflow, just paste the link here.
http://stackoverflow.com/questions/5869825/when-should-one-use-a-spinlock-instead-of-mutex
nishadg
So is busy waiting good or bad with many sharers?
ggm8
@nishadg I think it could depend on how long each sharer is holding the lock for. If by many sharers, you are implying that the lock is constantly being grabbed by different threads, then busy waiting might be a good idea, since the resources wasted would outweigh the cost of causing threads to sleep/wake up or context switch.
Busy-waiting is bad because execution resources are being used to run the while loop when they could have been used to run other threads (such as the one we are waiting for to release a resource to make the condition X true).
Although busy-waiting wastes the CPU time, it has advantages in some cases. For example, if the cost of context switch is higher than running the while loop or the computation in the locked block is simple, the wasted time is neglectable. Another situation is to deal with priority inversion issues. If threads have different priorities, busy-wait may prevent threads with higher priority from suffering more priority inversion. This is important especially in real-time system.
Busy waiting can also be beneficial in multinode systems without shared memory, if a node only has one thread running on it and is waiting for computation on another node to complete.
@rc303 To add to that, even on a single node, if the total number of threads running is same as the number of available cores, we might as well busy wait!
@nemo, I think when the number of threads is same as the number of available execution contexts, busy waiting is still ok?
@life, for multiple execution contexts on a single core, busy waiting of one thread might hurt the performance of another thread actually holding the lock.
@life Why do you think so? The thread is running (busy waiting) and other runnable threads (in execution context) could do useful work using those resources.
@firebb Why would it hurt the performance if the thread holding the lock if the other thread is just spinning waiting for the lock? Shouldn't the one with the lock be able to execute without being affected by the fact that another thread is waiting for the lock?
@muchanon For busy waiting, multiple execution contexts will hurt the lock since the waiting threads will still be scheduled to run on the core even if they are not able to make any progress. On the contrary, in blocking synchronization, waiting threads will be de-scheduled, so that they will not affect the thread that is holding the lock.
@lya Just to make sure, are you referring to the case that a thread holding a lock requests memory and the context switches to another thread on the same core to hide latency, but that thread never ends because it is busy waiting for a lock acquired by the first thread?
I think whether "busy-waiting" is bad or not depends on the property of the "critical section". In Linux kernel programming, there's a similar question - When to use "mutex" and when to use "spin-lock"?
I find a cool discussion in StackOverflow, just paste the link here. http://stackoverflow.com/questions/5869825/when-should-one-use-a-spinlock-instead-of-mutex
So is busy waiting good or bad with many sharers?
@nishadg I think it could depend on how long each sharer is holding the lock for. If by many sharers, you are implying that the lock is constantly being grabbed by different threads, then busy waiting might be a good idea, since the resources wasted would outweigh the cost of causing threads to sleep/wake up or context switch.