Thread: cout and multithreading

"Busy Loop" is a loop that consists of pure computations, with minimal or no delays. That makes the CPU run at its maximum speed, creating ugly conditions for both software and hardware.

Originally Posted by GReaper

Oh, NOW I understand what you're saying! That's not the case, you see, because only one thread changes the variable and only the other reads it.

Okay, but that places a contrived limitation on your example: printFirst can only print ONCE, then printSecond can follow. Why use threads at all in that case?

So you are stubborn and think (again, I remember doing this myself), okay, so I'll use two variables, vice versa to one another. PrintSecond() waits for done_printing to be false, does its thing, sets a "done_printing2". Should work!

Two problems. The first is that this:

Code:

while (!done_printing);

Has the same effect as while(1), until done_printing is false. I think you know what that means:

Code:

int main() {
    while(1);
}

Run that and watch a CPU monitor. Guess what? You have maxed a core out, doing absolutely nothing but check a value as often as possible. Throwing a millisecond sleep in will reduce the load, but that is sort of contra the concept of multi-threading (and now you have put in more work that you would have had to do if you just LEARNED TO USE THREAD SAFE LOCKS). [Okay Mr. Advocacy-for-the-devil :O, after posting this I notice you do know what a "busy loop" is. So I presume that really was the "mischievous method", lol]

Ie, in the "while(whatever)" case, threading is now worse than pointless. You are using two cores to do what is supposed to be done with one.

Real thread locks leave a waiting thread in a sleep state; they do not use any resources and are awakened when a condition is met.

The second problem is that reading any variable, including a bool, is a non-atomic process, meaning it can be half read, half changed, then the read finished. Which *might* be harmless in the case of a bool, but since the standard does not promise anything about how bools are represented, you will be banking "undefined behavior".

Thread-safe locks are simple to use (they generally work more or less like your "control variable", but have more under the hood). Other than complete laziness ("I want to write a multi-threaded program, but I do not want to have to read or obey any instructions"), there is no reason not to use them.

Originally Posted by Elkvis

Elysia, you mentioned that a busy loop is a bad idea. I don't disagree, but what do you recommend in a situation where the main thread spawns a large number of worker threads, and you need to wait for them all to complete before continuing in the main thread? it seems to me that some sort of loop that checks the threads to see if they are finished is exactly what is needed. sure, you could call pthread_join() (or its equivalent in whatever thread implementation you're using) on all of them, but if you need the main thread display the progress of the operation on the console, a loop would be about the only way to make that happen.

No. You use a mutex locked condition variable (qv. pthread_cond_t) -- or something similiar.

Relax, @MK27! I'm not raging a war against thread-safe locks... Forget I even mentioned it! ( Although it does work! )

Originally Posted by GReaper

Relax, @MK27! I'm not raging a war against thread-safe locks... Forget I even mentioned it! ( Although it does work! )

I think you mean "it seems to usually work for me here". :P

Originally Posted by MK27

[Okay Mr. Advocacy-for-the-devil :O, after posting this I notice you do know what a "busy loop" is. So I presume that really was the "mischievous method", lol]

Just what the world needs, more geniuses.

Originally Posted by Elkvis

Elysia, you mentioned that a busy loop is a bad idea. I don't disagree, but what do you recommend in a situation where the main thread spawns a large number of worker threads, and you need to wait for them all to complete before continuing in the main thread? it seems to me that some sort of loop that checks the threads to see if they are finished is exactly what is needed. sure, you could call pthread_join() (or its equivalent in whatever thread implementation you're using) on all of them, but if you need the main thread display the progress of the operation on the console, a loop would be about the only way to make that happen.

There are several ways.
You could use a a sleep/polling hybrid, which works sort of each X milliseconds, check and update progress. Can be done with a simple sleep and polling if threads are complete, or waiting for threads with a timeout.
Another way is to have a separate thread do this work, which can be signaled by the main thread to exit.
A third way is to simply use events. This works best when there are not so many updates, like a slow moving process. The threads will basically signal an event that a separate thread waits for as there is new progress available, again waiting for the main thread to signal it to quit.
I'm not going to discuss which method is best. There are ups and downs with all of them. But they all beat pure busy loops.

Originally Posted by GReaper

Relax, @MK27! I'm not raging a war against thread-safe locks... Forget I even mentioned it! ( Although it does work! )

Well, at least it made for a good discussion on thread safety.