[cpp-threads] N2880 and thread_local variables

Beman Dawes bdawes at acm.org
Tue Jun 9 02:27:36 BST 2009


On Mon, Jun 8, 2009 at 6:15 PM, Anthony
Williams<anthony at justsoftwaresolutions.co.uk> wrote:
> Hi,
>
> I have been thinking about the issue of thread_local variables with
> destructors and lifetime that is discussed in N2880, and would like to
> suggest a possible solution.
>
> My suggestion is this: create a new class thread_local_context which is
> intended to be used in an RAII manner. Creating an instance creates a new
> context on the calling thread for thread_local variables to be associated
> with. When the object is destroyed it destroys all thread_local variables
> modified on this thread since it was created.
>
> Destroying such an object from a thread other than that in which it was
> created would be an error, as would destroying such objects in any order
> other than the reverse of their construction within a single thread.
>
> Nesting such objects would create a new (blank) context for thread_local
> variables, and the outer context would be restored when the nested object
> was destroyed. Alternatively, nested contexts could inherit the set of
> thread_local variables from their parent context, and just destroy any
> newly-set values when the nested context is destroyed.
> "ready" flag on the future outside the scope, thus ensuring that the thread
> locals are destroyed before any waiting threads see the future as set.
> Hypothetically:
>
> std::packaged_task<FunctionSig>::operator()(Args... args)
> {
>    {
>        thread_local_context context;
>        try
>        {
>            associated_state.set_value(stored_func(args...));
>        }
>        catch(...)
>        {
>            associated_state.set_exception(std::current_exception());
>        }
>    }
>    associated_state.mark_ready();
> }
>
> If we made this facility available directly to users then they could use it
> wherever they were using facilities other than thread::join to signal thread
> completion. It could also be used inside any std::async function to avoid
> the lifetime issues raised in N2880.
>
> Obviously, this class would need to be intimately tied into the compiler's
> thread_local implementation.
>
> Comments?
>
> Anthony
> --
> Author of C++ Concurrency in Action | http://www.manning.com/williams
> just::thread C++0x thread library   | http://www.stdthread.co.uk
> Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
> 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>



More information about the cpp-threads mailing list