After repeated crashes at random times in my heavily threaded program, always in the destructor for a specific std::wstringstream object that only exists for literally 3 lines of code, I did some research, and I'm hearing whispers here and there that stringstream objects may not be entirely thread safe. This thread from the boost mailing list seems to be the strongest thing I've come across: http://lists.boost.org/Archives/boost/2006/09/109907.php Does anyone have some more info on this? Also, if stringstreams aren't thread safe, does anyone have any suggestions on what to use instead?

To add to what Promit said, although the standard library does not attempt to be threadsafe it may appear to be. Adding things to buffers for example, unless heavily used by multiple threads (and even in this case) may appear to be threadsafe because the adding is so simple.

Quote:Keep in mind that C++ is not thread-aware and so the standard library makes no attempt to ever be thread safe about anything. You will generally have to handle locking yourself.

That's a fair point, but there has to be a limit to that line of thinking. I haven't read every line of code for every standard library, nor do I plan to. I mean, I use std::string and std::vector everywhere. I've never looked at the code for them. I've got no plans to wrap global locks around every access to a vector or string object just in case it's not thread safe. If I can't have any confidence in the C++ standard library in a multithreaded program, that's a BIG problem for me. I use the STL to make programming easier, and to reduce errors. Most of my apps nowadays are multithreaded, and I've got no intention of re-writing the STL.

The simple fact is, C++ is moving into a more "thread aware" state. C++0x should introduce native threading support. With that, I would expect the standard library itself to become thread safe, or at least, for the rules to be clearly spelt out. I just want to work around this minefield until it's cleared. My concern right now is the stringstream class. My exposure to the STL in general is limited, and I can control access to any affected areas, I just need to know what exactly needs to be controlled. I've been coding in C++ for 10 years now, and this is the first I've heard of a stringstream potentially not being thread safe. Where does this end? Does it affect the iostream library itself? Does anyone have a list of known safe or known danger areas?

Consult the documentation for your standard library implementation. For example, for MSVC, there's a document titled "Thread Safety in the Standard C++ Library" in MSDN that details what threading guarantees the MSVC standard library implementation provides.

Quote:If your stringstream is created, used, and destroyed as an automatic variable by a single thread, it should be entirely threadsafe, unless your std::allocator is not threadsafe.

Are you absolutely sure about that? In the absence of anything to the contrary, I would assume the same thing. I did assume the same thing. Right now though, all I can say is I'm getting random crashes in the destructor for stringstream objects. It's either a buffer overflow in some random part of my code (and I've virtually ruled out that possibility already), or it's not in my code at all.

Quote:Original post by SiCrane
Consult the documentation for your standard library implementation. For example, for MSVC, there's a document titled "Thread Safety in the Standard C++ Library" in MSDN that details what threading guarantees the MSVC standard library implementation provides.

Thanks, I'll look that up. I am using VC++2005 BTW.

Quote:Original post by Nemesis2k2
The simple fact is, C++ is moving into a more "thread aware" state. C++0x should introduce native threading support. With that, I would expect the standard library itself to become thread safe, or at least, for the rules to be clearly spelt out.

The rules are clearly spelled out by implementations. At this point, pretty much all new versions of them have the same rule: Containers allow unlimited concurrent reading, but writing requires exclusive access to that container. Older versions have some thread-unsafe-on-read CoW stuff... offhand, I think that's limited to std::basic_string and its derivatives.

Oh, and for the record, I am talking about thread safety in the context of two completely separate, independent objects being created and used at the same time in separate threads, NOT two separate threads accessing the same object at the same time. This should be thread safe, as long as the objects don't rely on a common global or static variable. Sorry, I just realised I never qualified this.