while(true) vs wait+condition synchronism

Is it a bad practice to put a thread in a while(true) loop and test if a condition is ok to start a treatment?

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

is it preferable to use wait/condition mechanism :

void run()
{
    for(;;)
    {
 开发者_如何学C       if(dataReady)
        {
            processData();
        }
        lock_guard lock(mutex);
        condition_.wait(lock);
    }
}

Another thread of course calls condition_.notify_one()

EDIT:

I expect to almost never wait.

---

while true is a bad way because it just eats processing cycles.
Second approach is better, where in the thread gets intimated only when it has to perform some work.

---

It depends on the amount of time you expect to be waiting.

For very short periods a busy-wait can be preferable because it wouldn't involve a context switch as the other technique. The overhead of the context switch may sometimes overweigh the whole busy-wait loop.

---

If you do it the first way you'll need to ensure that the compiler actualy reads the variable from memory and doesn't optimize out the reads from memory as the value can't change inside that loop. Declaring the variable as "volatile" is necessary to do this.

But that on it's own is not sufficient. You need some form of memory barrier to ensure that changes to the variable in one thread are visible to the other, and the stores and reads don't get reordered by the CPU and cache. If this is on x86 you'll probably get away without it. But if you want to do this kind of thing you're much better using compiler intrinsics such as InterlockedIncrement (on windows, or similar on other platforms).

For almost all cases you're better using a condition variable, or a spin lock from a library (which is essentially what you are trying to implement) because they'll get the details correct for multi core processing.

---

It is always much more advised to do the latter. But this is a basic question in any threading or concurrent treatise...

In older processors, where there was only one thread, and where the power was consumed no matter what the processor was doing, this was a common idiom to wait for things. Now processors have several threads that can advance, and also they are intelligent enough to not to spend power if you're just waiting on a condition.

---

The former is usually a terrible idea because you'll use 100% CPU on one core doing nothing. You'll eat up resources that could've been used by some other thread (perhaps the one that was supposed to set dataready.

In the second example, the thread is put on hold until it is notified. So it doesn't eat up CPU time.

---

Yes, it is bad practice. Busy loops are a legitimate design choice only in places where sophisticated constructs like locks and threads are not available.

Although, if you can guarantee that your software is the only application running on the device (might be the case in embedded projects) you can possibly resort to a busy loop.

But in general, please avoid them.