Andrey Semashev <andysem <at> mail.ru> writes:
Anthony Williams wrote:
Andrey Semashev <andysem <at> mail.ru> writes: 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. :)
Quite possibly.
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?
This isn't hard to do: the underlying code does this anyway.
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.
How is this to be managed? Cleanup handlers for the TLS key need to run in the context of each thread, and only run when a thread changes its value with reset(), or when the thread exits. You cannot invoke a cleanup handler for another thread.
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.
The way the interface works at the moment, TLS data is implicitly associated with a specific thread_specific_ptr instance. It is fundamentally not copyable or movable, because doing so would invalidate the references to the instance from other threads. Using shared_ptr as you suggest is exactly the way to do this. The thread_specific_ptr is a bit clunky altogether. I intend to come up with something better in the future, but it may be moot once compilers start implementing the new thread_local storage duration. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL