Re: [boost] [thread] Questions about TSS

From: Andrey Semashev (andysem_at_[hidden])
Date: 2008-03-03 11:38:09

Anthony Williams wrote:
> Andrey Semashev <andysem <at> mail.ru> writes:
> 
>> Hi, I have a couple of questions about thread_specific_ptr in 1.35.
>>
>> 1. I can see that there is an ability to set up a logic of reclaiming
>> resources that thread_specific_ptr points to. Why is it limited (a) only
>> to a pointer to function and (b) can only be set up in
>> thread_specific_ptr's constructor? It might be better to provide
>> interface similar to shared_ptr in this way? 
> 
> a) The interface is how it was in boost 1.34 and prior. The underlying code
> would allow something more general, but I haven't updated the interface for that
> yet.

So I guess, I may hope this more general interface will be implemented?
In 1.36, maybe? Thanks in advance. :)

> b) If it wasn't set up in the constructor, it would have to be set up with every
> call to reset. There's arguments either way. This is the boost 1.34 (and prior)
> way.

Yes, and I see nothing bad with it. Shared_ptr does precisely the same,
and since this cleanup function is intended to do the same as
shared_ptr's deleter does, I don't see why would the interface have to
differ.

The only tricky thing here is that different threads could assign
different cleanup functions to the same pointer. But that isn't very
hard to implement, is it?

>> 2. Why thread_specific_ptr isn't copyable? Why can't it share TLS keys
>> (or whatever it uses to find the thread-specific resource) in the
>> dynamically allocated cleanup object? I would expect
>> thread_specific_ptr, being a pointer as its name implies, to be copyable.
> 
> Fundamentally, the TLS key is the instance of thread_specific_ptr itself, which
> is therefore not transferable. If you could assign one instance to another, how
> would that affect other threads that had values associated with the old value
> stored in that instance?

If there are no other pointers that own that TLS key, the cleanup
functions for all threads are invoked, and the TLS key is released.

> If you can't change an object after construction, why
> do you need to copy it? You could just pass around a pointer or reference
> instead.

I'm not sure I got you right here. My case is quite simple. I have a
class that needs to store some data in TLS to avoid thread contention.
And I want to keep the class copyable. Now I have to have a member
"shared_ptr< thread_specific_ptr< MyData > >" to achieve that, and
that's quite clumsy, not to mention the overhead of such solution.