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: Peter Dimov (pdimov_at_[hidden])
Date: 2011-11-19 07:45:52

Phillip Hellewell wrote:
> 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?

Well, the spec is already written, and not by us.

http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_key_delete.html

Even if we ignore the thread-specific allocation issue, I'm not sure I see 
how proper destruction can be implemented without imposing synchronization 
on the normal case. And the whole point of thread-specific storage is to 
avoid synchronization.

> 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.

You are right. There is no way to distinguish a stack-allocated Object from 
another stack-allocated Object created at the same address, so a map keyed 
by the object address can't work. Your other option may be unique per-object 
identifiers for use as keys, with ~Object somehow marking the identifier as 
invalid. But the "invalid identifier" set will soon grow out of hand and I'm 
not seeing a way to purge it. You could, perhaps, store a shared_ptr to a 
dummy identifier object and use the corresponding weak_ptr as a key, but I'm 
not sure that this is worth the trouble (and allocations) if stack use is 
rare.