Write->Read conflict and fprintf, fopen

[peter_schwer]

Write -> Read data-raceMemory read at "stream.c":67 conflicts with a prior memory write at "_flsbuf.c":137 (flow dependence)

Write -> Write data-raceMemory write at "_open.c":198 conflicts with a prior memory write at "_getbuf.c":50 (output dependence)

Read -> Write data-raceMemory write at "_getbuf.c":50 conflicts with a prior memory read at "_open.c":198 (anti dependence)

I am using win32 threads, VC++ 6.0 on winxpsp2

I am seeing the above error and other errors in the thread checker, all of which are related to the opening and reading of files.All of the errors reference a call to "fgets" or "fopen" or "fprintf", but none of them are working on the same file, so I am confused why they would be occurring.

The output of my application is correct, but I want some assurance that these errors can be safely ignored. I think perhaps I am linking into a non-threadsafe library that is used for file operations?

Thank you for your assistance.

[TimP]

Detection of non-thread-safe library use is an advertised function of thread checker. You should be linking the MT libraries provided with VC++, rather than simply depending on good luck.

[peter_schwer]

I have stopped relying on good luck- if what you say is correct, the thread checker would have alerted me if I was linking to non-thread-safe libraries. It has not mentioned anything of that nature. I am less familiar with the MT vs. non-MT windows libraries, but I assume that when you select "Settings...C/C++...Code Generation... Debug Multithreaded" in visual studio- it takes care of that.

Any other ideas?

[peter_schwer]

I resolved the conflicts by removing some diagnostic output that I had been printing on stderr in the main thread. Some of the worker threads did print out to stderr- but these statements were never referenced in the thread checker's conflict messages, and they never caused a problem in practice.

I'd behappy to have an explanation in any case.

[David_M_Intel3]

Hello Peter,

Using a multithreaded runtime library such a /MT as a previous person recommended is very important. When you are using Intel Thread Checker we recommend that you use /MDd - that is the multi-threaded debug dynamic runtime library (or at least /MD).

Intel Thread Checker instruments or inserts additional instructions into your application to track events and memory usage. When you statically link the runtime library, which is what happens when you select /MT, Intel Thread Checker just keeps right on instrumenting everything it encounters, not just the code you wrote/developed. In these circumstances Intel Thread Checker may report diagnostics in the runtime library that are false.When you use the dynamically linked version of the runtime library Intel Thread Checker recognizes the dll and gives special treatment to these system and runtime libraries and you avoid these falsely triggered messages.

So always use dynamically linked runtime libraries with Intel Thread Checker. When you build a release version you can always revert to the statically linked version if you really want to.

drmackay