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-17 19:46:04

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 <sshock_at_[hidden] 
> <mailto:sshock_at_[hidden]>> 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<thread_id, void*>, 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

--