I'm not exactly sure why we may prefer busy-waiting in a parallel program where it's likely to be the only (or one of the few) CPU-intensive programs running. Are we assuming that all other threads will also be waiting to acquire the lock on shared data, so none of them could do useful work even given resources?
jkorn
@yyc busy waiting is still doing work (although useless work), so a scheduler might keep the thread active instead of putting it to sleep and scheduling a thread in its place that can actually get meaningful work done (perhaps belonging to a different task altogether). However, the overhead of this scheduling and context switching is very high. So if there aren't really any other processes going on, and you only have one or two threads per execution context, then there's not really any more useful work that could be done if you swap off the thread, so spinning is preferred since you no longer need to deal with the extra scheduling overhead.
zckchange
Based on my understanding, when being compared with multi-threading, busy-waiting should occur between different Apps. Is it right?
It seems like here that if the cost of swapping threads is higher than the cost of being idle (spinning), then we ought to just spin.
blah329
@yyc to add onto what @jkorn said, busy waiting in a parallel program that has a very strict requirement on performance is ideal not only because of the overhead that might be incurred by causing a thread to block, and then making it runnable again during the unlock procedure, but also keep in mind how parallel programs are written. A system shouldn't be overloaded with requests, because as we saw in assignment 4, it can lead to poor performance and increases in latency; as such, one can assume that in a parallel program, not the system won't be overloaded, and as such if a thread busy waits, its fine, because other threads can probably still progress, assuming that they are all not contending for the same resource. Plus, keep in mind that in a parallel system busy waiting is also okay because one thread could be busy waiting on one execution context, while the thread that is using the resource is still making progress on another execution context.
atadkase
@blah329 You are probably talking about the case where different execution contexts are assigned to unique cores. Consider the case where you have multiple execution contexts on the same core. Won't it be better to rip-off a busy waiting thread if it is going to wait for a long time?
I'm not exactly sure why we may prefer busy-waiting in a parallel program where it's likely to be the only (or one of the few) CPU-intensive programs running. Are we assuming that all other threads will also be waiting to acquire the lock on shared data, so none of them could do useful work even given resources?
@yyc busy waiting is still doing work (although useless work), so a scheduler might keep the thread active instead of putting it to sleep and scheduling a thread in its place that can actually get meaningful work done (perhaps belonging to a different task altogether). However, the overhead of this scheduling and context switching is very high. So if there aren't really any other processes going on, and you only have one or two threads per execution context, then there's not really any more useful work that could be done if you swap off the thread, so spinning is preferred since you no longer need to deal with the extra scheduling overhead.
Based on my understanding, when being compared with multi-threading, busy-waiting should occur between different Apps. Is it right?
http://code.metager.de/source/xref/gnu/glibc/nptl/pthread_spin_lock.c
It seems like here that if the cost of swapping threads is higher than the cost of being idle (spinning), then we ought to just spin.
@yyc to add onto what @jkorn said, busy waiting in a parallel program that has a very strict requirement on performance is ideal not only because of the overhead that might be incurred by causing a thread to block, and then making it runnable again during the unlock procedure, but also keep in mind how parallel programs are written. A system shouldn't be overloaded with requests, because as we saw in assignment 4, it can lead to poor performance and increases in latency; as such, one can assume that in a parallel program, not the system won't be overloaded, and as such if a thread busy waits, its fine, because other threads can probably still progress, assuming that they are all not contending for the same resource. Plus, keep in mind that in a parallel system busy waiting is also okay because one thread could be busy waiting on one execution context, while the thread that is using the resource is still making progress on another execution context.
@blah329 You are probably talking about the case where different execution contexts are assigned to unique cores. Consider the case where you have multiple execution contexts on the same core. Won't it be better to rip-off a busy waiting thread if it is going to wait for a long time?