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

On 11/16/2011 11:00 PM, Phillip Hellewell wrote:

Anyone? Should I try boost-devel?

On Sat, Nov 12, 2011 at 4:00 PM, Phillip Hellewell mailto:sshock@gmail.com> wrote:

Hi,

My class contains a member var that is a little buffer used as a cache. Instances of this class are used concurrently (referenced through a shared_ptr).

I would like to switch my buffer to a thread_specific_ptr, but there are two big problems with using thread_specific_ptr as a member var: 1. There is a memory leak when my object goes away, because by design only one of the pointers gets cleaned up (the one for the thread that happens to delete the object). 2. There is undefined behavior when a new object gets created that happens to be allocated at the same address as a previously freed one. get( ) could return a pointer to a buffer that goes with an old (now freed) object.

I try not to question the wisdom of the thread_specific_ptr authors, but given these two issues, especially #2, I have to conclude that thread_specific_ptr is only suitable for statics / globals. It is wholly unfit to be used as a member variable (except in a singleton class I guess).

Hi Philip, I haven't used thread_specific_ptr. But I do feel like it was designed to handle cases like dealing with "errno" values, so each thread can handle them separately. You use a shared pointer to handle the objects lifetime. If all the threads that created the thread specific pointer values get destroyed before your object, the object is in good shape. 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.

The next best thing I can think of for my class is to just have a std::map, with synchronized access of course, and I clean up all the pointers in the map in the DTOR. That would work just great, except I really do need the pointers to also get cleaned up (and removed from my map) when the corresponding threads go away. Some of my objects can live a very long time, whilst threads get created and destroyed off and on, so without this functionality the map could grow indefinitely.

So I'm stuck. I can't use thread_specific_ptr because it won't clean up everything when my object goes away, and I can't use a map because it won't clean up anything when a thread goes away. Is there an easy solution to this?

If there were some way for me to hook up a callback directly to the thread cleanup function, I could add a callback to remove it from my map when the thread goes away. But I'd also need the ability to remove that callback in my DTOR. Does boost provide any way to do this?

--- 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? best arun

I can't be the first person to want a thread-specific, object-specific pointer, can I?

Phillip

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

--