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: Phillip Hellewell (sshock_at_[hidden])
Date: 2011-11-19 00:58:57

On Fri, Nov 18, 2011 at 2:04 AM, Peter Dimov <pdimov_at_[hidden]> wrote:
> Phillip Hellewell wrote:
>>
>> Glad to know I'm not the only one who sees this "feature" as a bug :)
>> I wonder how hard it would be to at least provide an option to clean
>> up all the TLS data when it is destroyed?
>
> Very. By specification, TLS cleanup occurs in the same thread that allocated
> the data (because the data may have been allocated by a thread-specific
> allocator). When thread_specific_ptr is destroyed, it obviously can't do
> that.

I can understand an argument against doing it if it is too hard, but
why is it so bad to change the spec to allow for an option as long as
it is clearly documented that it should not be used if you are using a
thread-specific allocator?

Put another way, why do we care more about protecting those who might
use a thread-specific allocator than protecting those who might use
thread_specific_ptr as a member var?

Ok, here's another idea: How about a new class,
object_specific_thread_specific_ptr! :)  Then we don't have to alter
thread_specific_ptr.

If nothing else, can we at least ask Anthony to add a Note to the
documentation warning against using thread_specific_ptr as a
non-static member var?

>> The only way I could use a static/global thread_specific_ptr is if it
>> pointed to a map of object (its address) to its buffer.
>
> Either map< weak_ptr<Object>, buffer > or set< weak_ptr<Object> > with map<
> thread_id, buffer > in the object, as I see it.

Hmm, say I never thought about using a weak_ptr to help me.  Let me
think about that for a bit...

>> But that puts me back in the same boat as I started in, with the same same
>> problems as trying to use a thread_specific_ptr as a member var.
>
> I'm not sure about that. Let's take the first option. What's the problem
> with it? No locks are needed, and in the function that creates a new map
> entry for the current object you can purge the expired weak_ptr entries in
> order to not let the map grow out of hand.

Ok, I think I understand how this could work.  There's only one tiny
problem though.  Although most of my code always creates an Object
inside a shared_ptr, it is allowed and there are some places that just
create one on the stack and use it, e.g., within a function.  Correct
me if I am wrong, but this idea can't work unless I forcibly disable
the ability to create an Object except via an Object::create() that
returns a shared_ptr.

Thanks,
Phillip