Re: boost::thread_specific_ptr problem

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-04-25 13:42:06

--- In Boost-Users_at_y..., "svanechel" <svanechel_at_y...> wrote:
> 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
>   }
> }

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