[cpp-threads] Asynchronous Execution Issues

Herb Sutter hsutter at microsoft.com
Mon Apr 27 15:38:26 BST 2009


> IIRC, this is what Hans is suggesting. It doesn't get away from the
> problem that destructors of thread_local variables are destroyed after

That's what I was missing: of thread_locals. Thanks.


> 1) Make it undefined behaviour for a thread_local destructor to access
> any objects of static storage duration.

I dislike this because it basically means a thread_local dtor can't call any library function it doesn't know the implementation of.


> 2) Provide a function which a thread can call that says "destroy
> thread locals NOW", and make it undefined to access any thread_local
> after that function returns.

This feels clunky, like a band-aid.


> 3) Provide a means for a thread to register a single function to be
> called after thread_local objects have been destroyed. It is undefined
> behaviour for that function to access thread_local objects, but it may
> call library functions. This function could then set the "done" flag.

> Another thought: if you need to know when a thread is finished, don't
> detach it: keep the handle around so you can join with it. This then
> requires that waiting on the future for an async() call also joins
> with the async() thread so we don't have this particular issue, but
> that doesn't strike me as a big deal. The downside here is that it
> makes it very hard to write async() yourself, since we haven't
> provided the means to write custom future internals.

FWIW I like these two options better than the other two. #3 is a general-purpose hook and therefore not a special-purpose band-aid. The last "then don't detach" sounds like useful advice in many cases anyway.


Thanks,

Herb



More information about the cpp-threads mailing list