[cpp-threads] Asynchronous Execution Issues (caching_async)

[Peter Dimov]

Boehm, Hans:
>I think we're also clear on the fact that the suggested solutions are 
>fairly drastic.  But I think the problems described in the paper are 
>serious.  If we had reasonable alternatives, I'd prefer not to be suggest 
>changes like this, especially at this stage.

The problems are real (but, I'd argue, not of our creation; they exist no 
matter what we do or not do).

It is quite interesting though, at least to me, to trace the implications of 
the proposed solutions. Anthony already pointed out that removing 
thread::detach implies that a "run in new thread" async would need to return 
the new "joining future" since it now has to store the std::thread object 
somewhere, and that ~future would need to join, as a consequence.

Removing TLS destructors would also have interesting implications. It would 
force people to use pthread_key_create instead, and currently, pthread_join 
is not guaranteed (by the spec) to wait for the destructors to complete 
(whereas we would presumably require std::thread::join to wait until 
thread_locals are destroyed). So this both reintroduces the problem _and_ 
renders the proposed solution ineffective (at least in theory).

And if we pretend that TLS destructors don't exist in our threading model, 
we effectively say that appications using thread-specific storage in any 
nontrivial way should only create a fixed number of threads and only join 
them at process exit. Which basically rules out the "new thread" async.

Incidentally, a function that destroys thread locals is also not a general 
solution since if one executes

    X f();

asynchronously, ~X has to run after the promise is set, and depending on X's 
allocator, may well return memory to a thread-specific free list.