[cpp-threads] Asynchronous Function Proposal

[Boehm, Hans]

> From: Peter Dimov
> Sent: Monday, June 08, 2009 2:58 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Asynchronous Function Proposal
> 
> Boehm, Hans:
> 
> > I'm still unsure what the programming rules for 
> thread_locals should be. 
> > And without that, it seems to be hard to answer these questions.
> 
> Thread locals simply have thread lifetime, just like ordinary 
> globals have process lifetime. It is up to the programmer to 
> use them correctly in case thread lifetime is needed (which 
> isn't very often.)
> 
> > I think most people are arguing for an approach in which 
> client code 
> > has to be very careful about storing unknown data D with nontrivial 
> > destructors into thread_locals, so that we can be sure that D is 
> > destroyed while it is still safe to do so, just as you would with 
> > static duration variables.  In that case, we might be able to allow 
> > running on another thread.
> 
> Yes. This really has nothing to do with async, or with its 
> ability (or not) to reuse threads. It is a general lifetime 
> principle. Threads do not introduce any qualitative 
> difference into C++ lifetime management. When you pass an 
> argument D into a function that you know may store D until an 
> event E happens, you make sure that D can handle it. It 
> doesn't matter whether the function is run in its own thread 
> or not, or whether E is the completion of its thread or some 
> other event (such as receiving a reply from a remote server 
> over TCP/IP, receiving a message from the window manager, or 
> the completion of an asynchronous file read).
> 
> > My only problem with this is that it makes it very hard to use 
> > thread_locals in generic library code, e.g. to cache the 
> last value I 
> > looked up in a map.
> 
> Not really unless the value doesn't have value semantics (a 
> copy is not a copy).
I think it's more than "value semantics", right?

Assume I have functions f() and g() in libraries L1 and L2 respectively.  Let's say g() caches its argument in a thread local, and f(g, x, y, z) may sometimes invoke g(y).  In order to be able to determine whether I can safely invoke f(g, x, y, z) from an async that may recycle threads, I think I need to know all of the above, at least if y's destruction relies on something of limited lifetime.  But standard library functions, for example, generally don't specify which arguments are invoked on which other arguments.  Hence it becomes hard to analyze if y may be destructed too late.

I'm not sure whether the correct use rules become too complex to be usable.

I agree that this would also be an issue with a static duration cache, for example.  But I suspect there are easier ways to work around it there, e.g. by "leaking" the cache contents.

Hans 

Hans