CString & operator = () thread safety ?

[wxuf]

hi ..

I have two threads running simultenous and a variable(global) are used by both threads, CString strFileName. Both threads will set this variable by the following expression : strFileName = strNewName .

I wonder whether it is safety to update the variable without any synchronize mechanize ?

CString & operator = () will call the "strcpy()" to copy strings. I think it is thread safety to function "strcpy()", am i right ?

wxuf

[Gabriel Fleseriu]

Directly from MSDN:
For size and performance reasons, MFC objects are not thread-safe at the object level, only at the class level. This means that you can have two separate threads manipulating two different CString objects, but not two threads manipulating the same CString object.

Obviously, this is meant without a synch mechanism. So, the short answer is no, th eoperator = os not thread safe.

[TheCPUWizard]

There is a difference between the documentation stating that a method is not guarenteed to be thread safe and the actual thread safety of a given method.

In this particular case, I can certify that the CString class (especially the assignment operator) is NOT thread safe.

The windows of vunerability is very small, but does in fact exist.

As a result of the window being small, many people have run "simple" tests and not seen a problem and made the wrong assumption...

[KristofU]

@TheCPUWizard :

Would you care to elaborate on the non-thread safeness of CString?
We recently switched our string copying mechanism from thread safe deep-copy to CString shallow copy.
Since our application uses 10+ threads, the shallow copy methods ( CString( const CString & ) and operator=( const CString & ) ) might very well be called concurrently.

I glanced at the current CString code and everything seemed to be OK. Although I must say I mainly looked for blatant thread-unsafe stuff.
After that I Googled and ended up here.

Before we analyze any further or start writing stress tests, I would really like an expert's opinion on this.

[TheCPUWizard]

The first thing I have to say is that my "analysis" was on VC 6.0, so many things might have been fixed. I am also doing this from memory from about 4 years ago....

The problem was a race condition when MODIFYING a string, specifically when the internal length had to be expanded.

There was also a problem with some of the "list" classes where multiple adds would overwrite.

Our solution was to create a wrapped "CSafe...." that used a ReaderWriter lock.

If you have looked at the current code, then your information is way more up to date than mine, and things may well be "fixed". But I would take care, things may change in the next version.

My advice to all my clients is: If something is not designed and/or documented to be threadsafe, then dont use it in a multithreaded fashion.