--- I like you last suggestion. But I can't find any way of doing it through boost threads. One thing I have to say though: if your design knows when to allocate the thread specific pointer, why doesn't it know when to deallocate it. If you're automatically allocating this cache at the beginning of a thread in each class object, expecting to deallocate at thread exit, maybe that's not the way to go. Is it possible to allocate it just when you need it and dealloc on exit of the method that needs it? I'm not allocating it at the beginning of a thread. Thousands of instances of this class can be instantiated on any thread at any time by several different places in the code, and these objects can get cached in global caches and then be used by other threads too. There's no way to know what thread might be the last one holding on to the object or removing it from the global cache. That's why I use shared pointers of course.
I just want to allocate the thread_specific_ptr when my object gets allocated (this works), -- When you say allocate, you just construct it right? I was talking about, when you call thread_specific_ptr->reset. This must be called within the context of a given thread inside a given function right? This is the point when you allocate "thread-specific" memory, which is not handled by shared_ptr cleanup. I'm assuming you have something like this: class MyClass{ thread_specific_ptr<MyCacheType> cacheptr;
On 11/18/2011 12:03 AM, Phillip Hellewell wrote: public: MyClass(){ } function_that_deals_with_thspptr(){ cacheptr.reset(new MyCacheType());//alloc thread specific memory; //use the memory ......... cacheptr.reset(0);//dealloc thread specific memory; } }; typedef shared_ptr<MyClass> MyClassRef; Do you not know when the need for cacheptr ends? I understand your project is much more complicated than above code. But I don't understand why you can't know when the need for the "cacheptr" ends. Your class objects can have a complicated lifespan. But you've shared_ptr to handle that, so no worries there.
and I want it to get destroyed, along with all the TLS data it allocated, when my object gets destroyed (this doesn't work; it's a known bug/feature of thread_specific_ptr). Phillip _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
--