cout and multithreading

So I noticed an issue tonight while testing a multithreaded program. In the effect of if two threads both try to cout at the same time they cut into each other, but not only that - it seems to have broken cout as all output to the console after that point never showed up. I use endl which if I remember flushes the stream after the call which doesn't clear the issue up. I am jsut curious what would be locked to keep the system from doing this to itself. For now I am removing the older cout as it was there for letting me know a connection was being culled from the server and the new one does the same just a bit more implementation specific. Looks like it broke fstream as well as the output file is mangled.... lol.

You could lock your stream buffers I guess, but to tell the whole truth, I'm not sure how much this will solve the problem.

ios::rdbuf - C++ Reference

Perhaps you could stuff the output in a stringstream buffer for each thread and just flush or read when the thread has control? If you don't share that data between threads it should alleviate the issue.

Will give that a shot thanks.

Quote:

---

Originally Posted by whiteflags

You could lock your stream buffers I guess, but to tell the whole truth, I'm not sure how much this will solve the problem.

---

It won't. No object (and that includes stream buffers) can protect itself from concurrent access. If two threads are concurrently accessing an object, those two threads need to synchronise access to the object.

Quote:

---

Originally Posted by whiteflags

Perhaps you could stuff the output in a stringstream buffer for each thread and just flush or read when the thread has control? If you don't share that data between threads it should alleviate the issue.

---

The trick to alleviate the issue is for each thread to synchronise their access (for example, using a mutex to determine which thread "has control") to the stream.

Each thread maintaining their own buffer can help, by reducing how often each thread needs to access the stream.

To my knowledge, the entire STL library is not thread safe (I could be wrong; there may be some exceptions). That simply means you must make sure to only access the same object from one thread at a time.

Quote:

---

Originally Posted by grumpy

No object (and that includes stream buffers) can protect itself from concurrent access.

---

you could certainly code a class so that it contains a mutex or some other locking construct as a member, and any attempt to perform an operation on an object of that type would implicitly attempt to lock that mutex, guaranteeing safe concurrent access. not sure if this is good practice, or if it's better for the coder to explicitly lock an object before attempting an operation on that object.

Quote:

---

Originally Posted by ~Kyo~

So I noticed an issue tonight while testing a multithreaded program. In the effect of if two threads both try to cout at the same time they cut into each other, but not only that - it seems to have broken cout as all output to the console after that point never showed up. I use endl which if I remember flushes the stream after the call which doesn't clear the issue up. I am jsut curious what would be locked to keep the system from doing this to itself. For now I am removing the older cout as it was there for letting me know a connection was being culled from the server and the new one does the same just a bit more implementation specific. Looks like it broke fstream as well as the output file is mangled.... lol.

---

On what operating system?

In Windows you would use Critical Sections... Critical Section Objects (Windows)

As in...

Code:

---

ThreadSafePrint()
    EnterCriticalSection()
        print your stuff
    ExitCricicalSection()

---

... and everything prints through that routine.

You can always try `std::ios::sentry', but it isn't guaranteed to do any strong locking.

Soma

The mischievous way: :D

Code:

---

#include <iostream>
#include <process.h> // Is this the one?

using namespace std;

volatile bool done_printing = false;

void printFirst(void*);
void printSecond();

int main()
{
    _beginthread(printFirst, 0, 0);

    while (!done_printing);

    printSecond();

    return 0;
}

void printFirst(void*)
{
    cout << "This prints first!\n";
    done_printing = true;
 
    _endthread();
}

void printSecond()
{
    cout << "This prints second!\n";
}

---

Warning: Untested! Use it at your own peril!! :D

Quote:

---

Originally Posted by CommonTater

On what operating system?

In Windows you would use Critical Sections... Critical Section Objects (Windows)

As in...

Code:

---

ThreadSafePrint()
    EnterCriticalSection()
        print your stuff
    ExitCricicalSection()

---

... and everything prints through that routine.

---

You need to stop using your C stuff. It's not exception safe, and it's not programmer safe. It's just unsafe all around! There is no reason at all to use it. One mistake and you get a deadlock.
Use boost, or the standard library for C++!

Sipher:
Your code is unsafe. It creates a race condition and it uses a busy loop, which is even worse.
There are perfectly standardized threading threading tools available, such as std::thread or boost::thread. They even have locks to prevent race conditions and allows you to actually wait for threads to complete instead of using busy loops.

Quote:

---

Originally Posted by Elysia

Your code is unsafe. It creates a race condition and it uses a busy loop, which is even worse.
There are perfectly standardized threading threading tools available, such as std::thread or boost::thread. They even have locks to prevent race conditions and allows you to actually wait for threads to complete instead of using busy loops.

---

Of course, I was just throwing an other idea. My example is neither practical nor sane for large implementations, but in this code it wouldn't hurt anyone... :)

Quote:

---

Originally Posted by Sipher

...but in this code it wouldn't hurt anyone... :)

---

But that is where I disagree.
Your code is broken in that it relies on race conditions.
And the fact that it uses a busy loop is unacceptable--at least to me--under any circumstance unless you can prove there is no better way to do it.

Quote:

---

Originally Posted by GReaper

Of course, I was just throwing an other idea. My example is neither practical nor sane for large implementations, but in this code it wouldn't hurt anyone... :)

---

No, you are wrong. I had ideas like this the first time I wrote a multi-threaded program, I'm sure a lot of people do because it seems like an obvious solution. I was wrong. You cannot attempt operations across threads without a thread-safe locking mechanism. This includes accessing simple variables. Why? How could, eg, a single byte value get messed up?

Here's how: done_printing is true. Thread A, running on core 1, loads the true value from RAM, meaning it can print. Great. Meanwhile, Thread B, running on core 2, loads the same true value from RAM, meaning it can print. Not so great. Now both threads set done_printing to false and proceed to screw up.

So all your idea does is move the problem from one place to a different place, and when that goes wrong, the original problem will re-emerge.

@Kyo: You did not say what thread implementation you are using, but all of them have thread-safe locking mechanisms, because without such they would be near useless. Use them when you perform IO on a global stream such as stdout, just as you would use them when reading from or writing to any structure accessed by more than one thread. There are no other choices, that's how threads work.

Quote:

---

Originally Posted by MK27

This includes accessing simple variables. So all your idea does is move the problem from one place to a different place, and when that goes wrong, the original problem will re-emerge. End of story.

---

I didn't catch that part. What do you mean? Sure, my idea is a total crap but what exactly is the problem?!

EDIT: Oh, I read your addition...

Quote:

---

Originally Posted by MK27

Here's how: done_printing is true. Thread A, running on core 1, loads the true value from RAM, meaning it can print. Great. Meanwhile, Thread B, running on core 2, loads the same true value from RAM, meaning it can print. Not so great. Now both threads set done_printing to false and proceed to screw up.

---

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.

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.

"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.

Quote:

---

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.

Quote:

---

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! :p )

Quote:

---

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! :p )

---

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

Quote:

---

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.

Quote:

---

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.

Quote:

---

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! :p )

---

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