Geek Answers Handbook

While (true) vs wait + condition synchronism

Is it bad practice to put a thread in a (true) cycle and check if treatment is normal?

void run() { for(;;) { if(dataReady) { processData(); } } }

it is preferable to use a wait / condition mechanism:

 void run() { for(;;) { if(dataReady) { processData(); } lock_guard lock(mutex); condition_.wait(lock); } }

Another thread, of course, calls condition_.notify_one()

EDIT:

I expect almost never to wait.

+4
source share
6 answers

It depends on the amount of expected wait time.

For very short periods, wait-wait may be preferable because it will not include a context switch as another method. The context switch overhead can sometimes outweigh the entire busy waiting cycle.

+4
source

while true is a bad way because it just eats processing cycles.
The second approach is better when the thread is set only when it has to do some work.

+7
source

If you do this in the first way, you need to make sure that the compiler really reads the variable from memory and does not optimize reading from memory, since the value cannot change inside this loop. Declaring this variable as "volatile" is necessary for this.

But this alone is not enough. To ensure that changes in a variable in one thread are visible to others, you need some kind of memory barrier, and stores and readings will not be reordered by the processor and cache. If it's on x86, you'll probably leave without it. But if you want to do such things, you are much better off using the built-in compiler functions, such as InterlockedIncrement (on windows or similar on other platforms).

For almost all cases, you'd better use a condition variable or rotation lock from the library (which is essentially what you are trying to implement), because they will return the parts for multi-core processing.

+2
source

It is always much more recommended to do the latter. But this is the main question in any streaming or parallel treatise ...

In older processors, where there was only one thread, and where power was consumed no matter what the processor does, it was a common idiom to wait for things. Now processors have several threads that can move forward, and they are also smart enough not to waste energy if you just wait for the state.

0
source

The first usually terrible idea, because you will use a 100% processor on a single core without doing anything. You will have resources that could be used by some other thread (perhaps the one that dataready should have installed.

In the second example, the stream is put on hold until it is notified. Thus, it does not consume CPU time.

0
source

Yes, this is bad practice. Busy loops are a legit design choice only in places where complex designs such as locks and threads are not available.

Although, if you can guarantee that your software is the only application running on the device (perhaps this applies to embedded projects), you can refer to the busy cycle.

But in general, please avoid them.

0
source

More articles:


All Articles