Re: deadlock in filesystem?

Ken Alverson wrote:

"Russell Hind" wrote in message news:bej3f4$fqg$1@main.gmane.org...

I'm linking against the correct (static multithreaded) library, the potential problem is that there are two of them (albeit two of the same one). One in the thread dll, one in the exe.

I understand that, what I'm suggesting is that you can tell if your app is using the dynamic RTL and therefore link against a different version of the thread library that also links against the dynamic rtl. If it isn't using the dynamic rtl, then you have to do what you have done. You'd have to take a closer look at the thread library to see the effect of this, and see where the resources are allocated and released for the objects you are using. AFAICT, all the code for mutexes and threads lives in the thread .cpp src files so hopefully there shouldn't be a problem for these, not sure about other objects. (I use, but haven't had enough of a look at the source for condition) Maybe William can shed more light on this. If the acquisition/releasing of resources is all done in the thread .cpp sources, then there shouldn't be a problem as they will use the RTL linked into the DLL. If any of the code is inlined into headers, then there is a problem. the lock classes are inlined, but they only call method on the mutex which isn't inlined so they shouldn't cause problems. HTH Russell