Previous | Next --- Slide 12 of 35
Back to Lecture Thumbnails
yey1

The the choice depends on different scenario. If swapping the context for OS is more expensive, busy-waiting is a better idea. But how can we know which choice is less expensive in different scenarios?

ant

As with many things in Computer Science, there is no one right answer. As you mentioned, it depends on the context switching time of the OS under consideration and the behaviour of the program. Profiling the program and understanding if switching from one type to the other would result in better performance is the way to go.

bob_sacamano

I would presume that when you're working with a large number of cores, spinlocks are generally preferred - as the coherence lectures discussed, the interconnect traffic for frequently accessing a mutex from multiple cores can prove to be a significant bottleneck.

Split_Personality_Computer

Busy-waiting versus blocking sounds a lot like the embedded systems' problem of polling versus interrupts when getting information from another device. In both cases for busy-waiting and polling, your system is consuming a lot of empty cycles but the benefit is an almost instant response when their waiting is complete. Meanwhile, blocking and interrupts allow for pretty much "backgrounding" the current process while you wait for a response so that other things can be run, but at the hazard of maybe waiting longer than they should and causing delays related to the backgrounded program.

bpr

@bob_sacamano, the only difference between a pthread_mutex and pthread_spinlock is that the mutex may use the OS to deschedule, while the spinlock will keep spinning. The later slides explore how to implement the spinning part when there is significant contention.

wxt

So a block would be a programmer-defined scheduling command, where the code forces a context switch? And during busy waiting, the processor itself will decide when to interrupt spinning?