[cpp-threads] Asynchronous Execution Issues (caching_async)

[Lawrence Crowl]

On 4/27/09, Boehm, Hans <hans.boehm at hp.com> wrote:
> The more I think about these issues, the less comfortable I get
> with anything like caching_async.  Given the lifetime issues we've
> already been running into, the fact that caching_async essentially
> delays destruction of thread_local objects far beyond the context
> in which they were created seems really dangerous.

I have reached the conclusion that caching_async is more like a
thread pool than not.  It requires the same kind of management
that a thread pool requires, but simply removes restrictions on
synchronization between work units.

On that basis, I don't think the existing decision to not standardize
thread pools should apply to a caching async.

Note, that I do not think this decision applies to the "new thread
or this thread" async that Bjarne wanted.

> If I write a function that implements a parallel algorithm, I
> generally have no way of knowing whether any iterators I'm passed
> refer to local (automatic) objects or heap objects of limited
> lifetime.  But if I create a thread_local reference to them, I run
> the risk of accidentally accessing them long past completion of
> the requested task, in the destructor for the thread_local, with
> exceptionally disastrous consequences.  I don't know how easy it is
> to make such a mistake, but I can't convince myself that it would
> be rare.  In any case, this seems like way too dangerous a feature
> to introduce at this stage without any experience to back it up.

And Bjarne's async doesn't have that problem.

> Note that Java experience doesn't apply here.  Java has some
> issues with persistent thread-locals.  As Doug points out, they
> can largely be addressed.  But it doesn't share this kind of
> object lifetime issue.

-- 
Lawrence Crowl