cout and multithreading

This is a discussion on cout and multithreading within the C++ Programming forums, part of the General Programming Boards category; Elysia, you mentioned that a busy loop is a bad idea. I don't disagree, but what do you recommend in ...

  1. #16
    Registered User
    Join Date
    Oct 2006
    Posts
    2,370
    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.

  2. #17
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    "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.
    Devoted my life to programming...

  3. #18
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by GReaper View Post
    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.
    Last edited by MK27; 09-18-2011 at 10:01 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #19
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Elkvis View Post
    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.
    Last edited by MK27; 09-18-2011 at 10:02 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #20
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,624
    Relax, @MK27! I'm not raging a war against thread-safe locks... Forget I even mentioned it! ( Although it does work! )
    Devoted my life to programming...

  6. #21
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by GReaper View Post
    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

    Quote Originally Posted by MK27 View Post
    [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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  7. #22
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    Quote Originally Posted by Elkvis View Post
    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.

    Quote Originally Posted by GReaper View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Multithreading.
    By kevinawad in forum C++ Programming
    Replies: 5
    Last Post: 10-21-2008, 12:12 PM
  2. std::cout or using namespace std or using std::cout
    By ComDriver in forum C++ Programming
    Replies: 13
    Last Post: 01-31-2005, 10:54 AM
  3. Whats the difference between cout and std::cout?
    By mdshort in forum C++ Programming
    Replies: 10
    Last Post: 12-30-2003, 04:34 PM
  4. multithreading
    By thedumbmutt in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 11-13-2002, 10:54 AM
  5. Multithreading :: MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 10-03-2002, 08:39 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21