Faster than STL string class?

[Jakob Bieling]

You really have to define what you mean by thread safe for a string
handling package. If you mean that two threads should be able to
concurrently access the same string object, then I think no reasonable
implementation of std::string will do that because the overhead would be
HUGE.

If you just mean that distinct strings can be manipulated concurrently,
then the OP's implementation is just fine because it has no global
variable. The only global resource is memory, and thread safe versions
of new/delete are used in a threaded program.

Microsoft claims to provide a truly thread-safe version for
multithreaded applications of the string class, if I am not mistaken.

regards

 

[Kai-Uwe Bux]

Microsoft claims to provide a truly thread-safe version for
multithreaded applications of the string class, if I am not mistaken.

regards

What does "truly thread safe" mean? At most it means that all string
operations are atomic. Now, that is usually not even useful: if two threads
use modifying operations on the same string, none of them can make
reasonable predictions about the contents unless they lock the string for
some times and release the string once it is no longer necessary to know
about its contents.

There is a very well reasoned treatment about what thread safety could and
should mean for container classes on the SGI website for their (outdated)
reference implementation of the STL.

http://www.sgi.com/tech/stl/thread_safety.html

From there:
<quote>
The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct containers are safe, and simultaneous
read accesses to to shared containers are safe. If multiple threads access
a single container, and at least one thread may potentially write, then the
user is responsible for ensuring mutual exclusion between the threads
during the container accesses.
</quote>

This kind of thread safety is more or less automatic one you do not use
static variables in your container class.

Now, I would like to know how Microsoft differs.


Best

Kai-Uwe

 

[Jakob Bieling]

What does "truly thread safe" mean? At most it means that all string
operations are atomic. Now, that is usually not even useful: if two

threads

Yes, this is what I meant.

use modifying operations on the same string, none of them can make
reasonable predictions about the contents unless they lock the string for
some times and release the string once it is no longer necessary to know
about its contents.

There is a very well reasoned treatment about what thread safety could and
should mean for container classes on the SGI website for their (outdated)
reference implementation of the STL.

http://www.sgi.com/tech/stl/thread_safety.html

From there:
<quote>
The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct containers are safe, and simultaneous
read accesses to to shared containers are safe. If multiple threads access
a single container, and at least one thread may potentially write, then the
user is responsible for ensuring mutual exclusion between the threads
during the container accesses.
</quote>

This kind of thread safety is more or less automatic one you do not use
static variables in your container class.

Now, I would like to know how Microsoft differs.

I only read that using the multithreaded library also gives you a
thread-safe string version (I assume this applies not only the std::string,
but to any other container as well). To me, that would mean that
stimultanious write accesses are also synchronized. Basically what you said
above. But I might be misinterpreting something. I also found the article my
initial statement was based on:
http://support.microsoft.com/default.aspx?scid=kb;en-us;813810

regards

 

[Peter van Merkerk]

The m_capacity member is updated before new char[...]. If the new operator
throws an exception the CString object is left in an invalid state;
m_capacity member holds a value that does not reflect the actual size of
the allocated buffer.

That is exception safety, not thread safety.

Whoops, my mistake...I should learn to read next time...