[cpp-threads] Asynchronous Execution Issues (caching_async)

[Peter Dimov]

Hans Boehm:

> What scares me about the thread_local case here is that we're artificially 
> and somewhat surprisingly extending the lifetime of some objects. Consider 
> calling a function par_func(y) that internally invokes caching_async(), 
> which in turn runs a function that caches a copy x of some piece of y in a 
> thread_local.  If y and hence x happen to use, for example, an allocator 
> whose lifetime is limited to that of a caller to par_func(y), we 
> potentially end up with an asynchronous stack smash for the calling 
> thread.

I'd say that in general, objects that can outlive their storage (i.e. the 
memory can be reclaimed before the destructor runs) are inherently dangerous 
and passing them to unknown third-party code is a gamble either way, even 
with absolutely no thread_local support; these objects violate C++'s general 
lifetime principles in a fundamental way. A refcount and an assert in the 
allocator destructor seems not a bad idea. :-)

This aside, I agree that the thread_local case works (if join is guaranteed 
to wait) with a dedicated thread, and breaks with a thread pool. But note 
that the global case always breaks. It is not uncommon for functions to keep 
cached elements not in a thread local, but in a global data structure.

Placing the blame here is obviously a matter of opinion, but I'd be inclined 
to say that having to use a dedicated thread for a specific task - for 
lifetime reasons alone - means that the design is broken.