Re: Minimum VC++ for Multi-Core?
On Sat, 19 May 2007 11:31:38 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
On Sat, 19 May 2007 11:38:23 +0100, Daniel James <wastebasket@nospam.aaisp.org> wrote:
In article news:<0snr431usesfdh9iqmt67aph2rosb7ifmm@4ax.com>, Joseph M.
Newcomer wrote:
Well, since strings are not thread-safe, this just says that strings
are not thread-safe. I'm amazed that this is the only bug that was
reported, since it arises because of the use of a std::string by two
threads without synchronization.
There's more to it than that. The KB article is talking about a bug that
arises when two threads each have their own copy of a std::string but
(because of the COW implementation of strings in the rtl) these two
"copies" actually share a buffer (and a reference count).
The C++ Standard requires that std::string::reference be an actual
reference instead of a class type, and this forbids COW. It does allow the
poor substitute early string implementations used, which I call
"copy-just-in-case", because it unshares the string merely upon producing a
non-const iterator or reference, just in case the string is ever written
through them.
This is not simply a matter of using a single string and failing to
synchronize access to it from two threads, it is a matter of using two
separate strings and the smoke-and-mirrors that optimizes their use of
memory (in a manner that is supposed to be invisible to the user) failing
to provide synchronization.
In VS200x the implementation of std::string (and that of CString, too, BTW)
uses a small-string optimization rather than shared buffers and COW,
specifically to avoid such threading problems.
CString remains COW (real COW, that is).
Cheers,
Daniel.
But what was odd was that I didn't see any attempt in the VS.NET 2003 implementation to do
any synchronization at this level, either.
joe
What class and what level?
--
Doug Harrison
Visual C++ MVP