Subj : Re: Isn't libcmt thread safe ?!? repeated fopen() calls on multiprocessor machine return SAME file ptr!!!
To   : comp.programming.threads
From : Ben Hutchings
Date : Fri Sep 30 2005 05:57 pm

5spot <tal@givenimaging.com> wrote:
> Hi,
>
> I have a multi-threaded VisualStudio2003 C++ based application, which I
> am running on Win2000/WinXP. During stress testing on multi-processor
> workstations, I am seeing a stange error in which:
> 1.  a file creation call to fopen("xxx", "wt") returns a valid file
> pointer, and writes to the file are performed OK.
> 2. but then a another call to fopen("yyy", "wt") from another thread
> trying to create a different filename returns the SAME file pointer as
> the first fopen call. (although I did not fclose() the original...
> 3. From that moment on, all writing to the identical file pointers wil
> result in writing to the second file.

Where are the file pointers stored?

> - I am using AfxBeginThread() to create the threads.
>
> - This only occured on multiprocessor machines, and not on single
> processor machines.
>
> - I am using the libcmt (thread safe runtime library)
>
> - So far, replacement of the runtime library calls like fopen() /
> fwrite()... with Win32 calls such as CreateFile() and WriteFile() seem
> to have fixed this, but I do not understand how this could happen in
> the first place.
>
> It smells like a thread safety issue with the "thread safe" runtime
> library version, but I have not found any internet links describing
> similar things.

I had a look through the code behind fopen() and fclose() in the MSVCRT
and I don't see anything that could cause this.  The stream allocator
does read stream flags without acquiring the associated stream lock,
but AFAICS that can only ever delay reuse of streams.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.

.