On Thu, Nov 17, 2011 at 5:46 PM, Arun Ramasamy
But if the object gets destroyed before all the threads, then you're expecting shared_ptr to do the cleanup for you (as in every time the ref count goes down you want the corresponding thread sp. obj to be destroyed). May be you can override one of shared_ptr's members, when ref count goes down, and reset the corresponding thread sp. obj's pointer (Not sure if this possible, but you can see if they have an extension for some cleanup during ref count downs). But the onus is up to you, not shared pointer to cleanup thread sp. stuff.
Hmm, that's a really interesting idea, but I don't know if I want to go mucking with overriding shared_ptr... That feels a little too scary.
--- 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), 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