Re: [Boost-users] How can I have an object-specific and thread-specific pointer?

Subject: Re: [Boost-users] How can I have an object-specific and thread-specific pointer?
From: Arun Ramasamy (aramasamy_at_[hidden])
Date: 2011-11-18 08:44:33

On 11/18/2011 12:03 AM, Phillip Hellewell wrote:
>> --- 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;
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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

--