In multithreaded programming, if we let a waiting thread continuously check whether a condition is met in a loop, and if it is, continue executing the corresponding processing operation, and if not, sleep for a while, can this achieve the same effect as using condition variables?
The method of polling with sleep can indeed implement basic waiting functionality, but it fundamentally differs from the use of condition variables in terms of efficiency, responsiveness, and resource consumption. It can be said that condition variables were designed specifically to overcome the shortcomings of the polling model.
The table below clearly illustrates the core differences between the two.
💡 Core Difference: From “Constant Inquiry” to “Passive Notification”
We can understand their essential difference as follows:
-
Polling with Sleep: It’s like asking a friend to keep an eye on whether a package has arrived, but he checks the mailbox downstairs every 5 minutes. Most of the time, he is making a wasted trip, wasting his energy (CPU resources), and there is a delay between when the package actually arrives and when he checks.
-
Condition Variables: This is like the delivery person having your phone number. When the package arrives, he will call you directly. During the waiting period, you can completely relax (not occupying CPU), and once the phone rings, you can respond immediately.
🎯 How to Choose: An Important Discussion
In the vast majority of scenarios requiring thread synchronization, condition variables are a far superior choice compared to polling with sleep, as they can efficiently coordinate thread execution and avoid unnecessary resource waste.
However, an interesting and counterintuitive discussion arises in extreme scenarios that pursue low latency and have abundant CPU resources (such as core engines for high-frequency trading), where some developers find that very short busy-waiting (even without sleeping) or its variants (like sleeping for 1 microsecond) may respond faster than condition variables.
This is because the <span>wait</span> and <span>notify</span> operations of condition variables involve the operating system’s thread scheduling, requiring two context switches (blocking the waiting thread and waking up the waiting thread), which incurs certain overhead. While polling at very short intervals wastes CPU, it avoids scheduling overhead. Tests have shown that in some cases, the response time of condition variables can be about 10% longer than microsecond-level sleeps.
But please note that this is merely a special strategy for extreme performance optimization, sacrificing significant CPU resources for a slight reduction in latency, and is not suitable for ordinary applications. A common compromise is the “hybrid model“: polling for a short time, and if the condition is not met, switching to condition variables for waiting.