cout and multithreading

[~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.

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

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.

[~Kyo~]

Will give that a shot thanks.

[grumpy]

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.

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.

[Elysia]

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.

[Elkvis]

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.

[CommonTater]

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

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

... and everything prints through that routine.

[phantomotap]

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

Soma

[GReaper]

The mischievous way:

#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!!

[Elysia]

On what operating system?

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

As in...

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.

[GReaper]

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

[Elysia]

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

[MK27]

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.

[GReaper]

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

[GReaper]

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.