Synchronizing STD cout output multi-thread

First of all, you might consider avoiding all the explicit thread management, and instead use std::async to launch your tasks in some arbitrary number of separate threads.

Second, instead of doing the I/O in the threads themselves, you want to create results, and do the output itself serially. This means the thread function just creates some data, and leaves it to the caller to actually write that out:

std::string process(int value) {
     std::ostringstream buffer;
     buffer << "my" << std::setfill('0') << std::setw(2) << value;
     return buffer.str();
}

Then we need to launch four copies of that asychronously:

std::vector<std::future<std::string> > results;

for (int i=0; i<4; i++)
    results.push_back(std::async(std::launch::async, process, i));

Then we get the results and print them out in order:

for (auto &r : results)
    std::cout << r.get() << "\n";

Putting those together, we could get code like this:

#include <string>
#include <iostream>
#include <thread>
#include <future>
#include <sstream>
#include <vector>
#include <iomanip>

std::string process(int value) {
     std::ostringstream buffer;
     buffer << "my" << std::setfill('0') << std::setw(2) << value;
     return buffer.str();
}

int main() { 
    std::vector<std::future<std::string>> rets;

    for (int i=0; i<4; i++)
        rets.push_back(std::async(std::launch::async, process, i));

    for (auto & t : rets) {
        t.wait();
        std::cout << t.get() << "\n";
    }
}

I should add one minor point: I'm basing this on standard C++11 futures. I believe the basic idea should also work with Boost futures (upon which the standard was based) but I haven't tested that. I'd expect that some minor adjustments (e.g., to names) will be needed to work with Boost's futures.

I resolved it by coding up a thin wrapper that locks a mutex on starting writing to the stream and releases it, along with flushing the stream, once the write statement is completed.

Usage: replace std::cout by safe_cout.

Keep in mind it does not support fancy std::cout features like std::endl.

See the code below or grab it from here: https://github.com/dkorolev/felicity/blob/master/safe_ostream.h

#include <cassert>
#include <iostream>
#include <mutex>
#include <memory>

struct safe_ostream {
  struct guarded_impl {
    guarded_impl() = delete;
    guarded_impl(const guarded_impl&) = delete;
    void operator=(const guarded_impl&) = delete;
    guarded_impl(std::ostream& ostream, std::mutex& mutex) : ostream_(ostream), guard_(mutex) {
    }
    ~guarded_impl() {
      ostream_.flush();
    }
    template<typename T> void write(const T& x) {
      ostream_ << x;
    }
    std::ostream& ostream_;
    std::lock_guard<std::mutex> guard_;
  };
  struct impl {
    impl() = delete;
    void operator=(const impl&) = delete;
    impl(std::ostream& ostream, std::mutex& mutex) : unique_impl_(new guarded_impl(ostream, mutex)) {
    }
    impl(const impl& rhs) {
      assert(rhs.unique_impl_.get());
      unique_impl_.swap(rhs.unique_impl_);
    }
    template<typename T> impl& operator<<(const T& x) {
      guarded_impl* p = unique_impl_.get();
      assert(p);
      p->write(x);
      return *this;
    }
    mutable std::unique_ptr<guarded_impl> unique_impl_;
  };
  explicit safe_ostream(std::ostream& ostream) : ostream_(ostream) {
  }
  template<typename T> impl operator<<(const T& x) {
    return impl(ostream_, mutex_) << x;
  }
  std::ostream& ostream_;
  std::mutex mutex_;
};
safe_ostream safe_cout(std::cout);
safe_ostream safe_cerr(std::cerr);

You either need to impose an order on the threads so that the ordering of the output is as you want, (perhaps by passing thread-instances or events to the appropriate threads so that they can only execute in your order), or you could give all the outputs a thread-sequence number, queue all the outputs to one 'print' thread and, in there, keep a list of any out-of-order lines so that the printout is as you want.

In the case of a 'real' app, (ie. not a trivial test app that misuses threads), where the threads do a lot of work in parallel on sequential buffers whose order must be preserved, forcing threads to wait for each other is not usually a reasonable option. It's usual to use sequence numbers and reassemble the buffer-stream afterwards.