Re: Thread safety in iostreams
mattb wrote:
In attempting to learn more about iostreams I have been mucking around
with some classes which I have derived from streambuf classes to
provide output to some external representations. By overloading
virtual fucntions overflow, and sync and providing functionaliy to
flush a buffer as required I am able to create streambufs which work
quite nicely. Nicely that is as long as I restrict their usage to
single threaded applications. As soon as I move to multithreaded apps
all sorts of problems arise. The following is a simpified version of
code that is heavily based on book based examples I have reveiwed set
up in this case to create a console window and write to that...
<snip - ostream and streambuf class>
So,
mystream<console> consolestream;
will create a stream object which will write output to a console
window. All is hunky dory until I test in a multi threadded app when
it immediately starts crashing. I can see that the problem is that
the write buffer is incorrectly placed and memory is trashed, I assume
this is as a second thread calls the streambuf flushbuffer method and
recalculates the 'num' value whilst another thread is in the middle of
a flushbuffer call also. I.e. thread one is writing a 10 char
string, calculates the offset num, writes the string and then before
the write pointer is reset another thread two recalculates the offset
to be for example 100 causing the write pointer to reset to an address
way before the start of the buffer. And I can stop this behaviour by
using a locking mechanism in the flush buffer method. My question
is... is this the correct approach to take?
That depends. For your consolestream to be usable in multiple threads,
you need some kind of locking. As the consolestream objects seems to be
shared across the threads, you need either locking in *all* the methods
that access/modify the pointers that refer to your buffer. Or each use
of the consolestream object must be protected.
I understood that the
iostream objects handled their own locking on write operations through
their nested senrty objects, making the stream objects safe for
multithreaded use. Where is my understanding of this iostream locking
wrong?
I am not sure where you got the notion that the sentry objects enable
shared use across threads, because they are not required to do so.
The C++03 standard does not recognise the notion of multiple threads, so
it can not make any requirements that imply their existence.
And the draft of the next standard has the same requirements on
std::ostream::sentry objects as C++03.
So, in short, there are NO requirements that streams can be shared
across threads.
Also, if I correct the behaviour I see by adding the locking
mechanism then I still get intermixed outputs in the output stream. I
can see why this is the case but it is annoying. Is it possible to
prevent this mixing?
Yes, by ensuring the entire output statement is enclosed by a single
pair of locks.
You could, for example, use something like this helper class to lock an
output sequence:
template <class Mutex, class Stream>
class stream_locker;
template <class Mutex, class Stream>
stream_locker<Mutex, Stream> lock_stream(Mutex& mtx, Stream& os);
template <class Mutex, class Stream>
class stream_locker {
Stream& os;
Mutex& mtx;
friend stream_locker lock_stream(Mutex& mtx, Stream& os);
static int copy_count;
stream_locker operator=(const stream_locker&); // not implemented
stream_locker(Mutex& aMutex, Stream& aStream) :
os(aStream), mtx(aMutex)
{
mtx.lock();
copy_count = 1;
}
public:
stream_locker(const stream_locker& rhs) :
os(rhs.os), mtx(rhs.mtx)
{
copy_count++;
}
~stream_locker()
{
if (--copy_count == 0)
{
mtx.unlock();
}
}
template <class T>
Stream& operator<<(const T& rhs)
{
os << rhs;
return os;
}
Stream& operator<<(ostream& (*pf)(ostream&))
{
os << rhs;
return os;
}
Stream& operator<<(ios_base& (*pf)(ios_base&))
{
os << rhs;
return os;
}
}
template <class Mutex, class Stream>
stream_locker<Mutex, Stream> lock_stream(Mutex& mtx, Stream& os)
{
return stream_locker<Mutex, Stream>(mtx, os);
}
//Usage:
lock_stream(aMutex, consolestream) << "Here " << "is " << "some " <<
"atomic " << "output" << endl;
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]