Re: [boost] [thread] Questions about TSS

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-03-03 12:41:11

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