Reputation: 245
I've been looking for an answer to this question for a day now and cant find a straight forward answer. I'm reading up on context switching waiting queues and stuff like that do get a good grasp of everything .And when reading an article there was written that when a convoy situation occurs, there will be a lot of context switching. So let me get this straight lets presume a thread is in a waiting queue for a mutex to unlock, does the cpu constantly context switch to that waiting thread to see if the mutex that its waiting for is unlocked. If that's true that means that everytime a thread is waiting for a mutex to unlock or a notification of a condition variable, the cpu context switches to those threads for a check up. Am i correct? Thanks for your help.
Upvotes: 2
Views: 808
Reputation: 171178
I assume we are talking about OS-level mutexes (no user-mode spinning).
The OS will permanently deschedule waiting threads until the mutex becomes free. Only when a mutex that is being waited on is unlocked the OS will schedule one or more of the waiting threads to resume execution.
This means that there is no overhead caused by waiting threads. There is no busy-loop spinning ("switching") in the OS. There is need for that because the OS just unblocks waiters at the moment the mutex becomes available.
Imagine all threads were waiting on a mutex that is never being released. In that case the waiters would never run and they would never be switched to.
Upvotes: 2