boost::thread_specific_ptr problem
Hi there, I've encountered a curious problem when using thread_specific_ptr. We are developing a Win32 Service and for each thread we need an object that stays alive for as long as the thread runs (except for the main thread). So we created a dll and in its DllMain function we did something like this: boost::thread_specific_ptr<SomeClass> someClass; BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved ) { switch ( fdwReason ) { case DLL_THREAD_ATTACH: someClass.reset( new SomeClass ); // Breakpoint 1 case DLL_THREAD_DETACH: someClass.reset(); // Breakpoint 2 } } And now comes the curious bit: If you build this dll and implicitly link it with the exe the exe's startup code hangs in GetModuleFileName (). This is the call stack upto that point _setargv (STDARGV.C) __getmainargs (CRTLIB.C) WinMainCRTStartup (CRTEXE.C) At that point the code hasn't reached Breakpoint 1 yet (it's still in the exe's startup code in the main thread and we are not interested in the main thread) It is not the class we are allocating. We tried it with an empty class and that produced the same result. However, if we stored an object in a TLS slot allocated with the API, everything works. It probably has nothing to do with the exe being a service either, since the same dll with linked to a normal exe had the same problems. To complicate matters even further we reached Breakpoint 1 in a number of runs, but as soon as we left DllMain in those instances the application hanged again. If you break then you see from the call stack that the code is running somewhere in NTDll. Are we using thread_specific_ptr in a way that it wasn't meant to be used, or did we encounter a real problem here? I've used thread_specific_ptr before and had no problems then. PS: We develop under Windows 2000 on a Compaq Evo W6000 dual processor machine, using MSVC 6, SP 5 and the 08/2001 version of the platform SDK. The service can run both under the Local System Account or under an account with absolutely no privileges at all. Sven Van Echelpoel
Hi there,
I've encountered a curious problem when using thread_specific_ptr. We are developing a Win32 Service and for each thread we need an object that stays alive for as long as the thread runs (except for the
thread).
So we created a dll and in its DllMain function we did something
--- In Boost-Users@y..., "svanechel"
this:
boost::thread_specific_ptr<SomeClass> someClass;
BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved ) { switch ( fdwReason ) { case DLL_THREAD_ATTACH: someClass.reset( new SomeClass ); // Breakpoint 1 case DLL_THREAD_DETACH: someClass.reset(); // Breakpoint 2 } }
I hope you have a break point in there. Well, actually, it doesn't matter because of below.
And now comes the curious bit: If you build this dll and implicitly link it with the exe the exe's startup code hangs in GetModuleFileName (). This is the call stack upto that point
Likely what's causing you grief is that the thread_specific_ptr<> implementation uses a mutex, and locking a mutex within DllMain is verboten (it causes deadlocks). A similar problem was pointed out a few weeks ago about creating threads in DllMain. I'll be looking into ways to fix this, but in some cases there may simply be no solution.
Are we using thread_specific_ptr in a way that it wasn't meant to be used, or did we encounter a real problem here? I've used thread_specific_ptr before and had no problems then.
You're just using it in a way I didn't account for (and should have). This is a bug I have to try and fix, but the end result may be that you simply aren't allowed to use it this way. Bill Kempf
[...]
Likely what's causing you grief is that the thread_specific_ptr<> implementation uses a mutex, and locking a mutex within DllMain is verboten (it causes deadlocks). A similar problem was pointed out a few weeks ago about creating threads in DllMain. I'll be looking into ways to fix this, but in some cases there may simply be no solution.
Ah ok. Since by now more problems have surfaced we are trying another route. But thanks for the explanation. Sven.
participants (2)
-
bill_kempf -
svanechel