[cpp-threads] Asynchronous Execution Issues (caching_async)

[Boehm, Hans]

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Lawrence Crowl
> Sent: Monday, April 27, 2009 6:14 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Asynchronous Execution Issues 
> (caching_async)
> 
> 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.
I'm not sure that I'm parsing your comment correctly.  You are saying that we should not at this point pursue a caching async?  In that case, I agree.

> 
> Note, that I do not think this decision applies to the "new 
> thread or this thread" async that Bjarne wanted.
OK.  But if we went that route, I think we'd be ignoring existing practice in the form of Cilk or TBB, and standardizing something simpler that I would expect performs significantly worse, at least for a similar client programming model.
That might turn out to be a defensible position, but I'm currently way too confused to make that call.

Presumably, you would basically fork a thread if there are available processors.  But that may mean that even for a balanced tree-structured computation you may end up spending a lot of time forking very short-lived threads corresponding to tasks at the bottom of the tree, rather than forking at high levels of the tree.

You might still get acceptable results at sufficiently large granularity.  But this seems far more limited than Cilk.  And presumably Cilk was largely motivated by the inadequacy of this kind of solution.

The programming model seems similarly restrictive in that I can't allow arbitrary synchronization between tasks.  Locking seems OK, so long as I don't hold locks while invoking an async.

The "new thread or this thread" async does have the advantage that we don't have to deal with the "destruction of thread locals" issue.  (Presumably Cilk and TBB currently assume that thread_locals don't have interesting detsructors?)

Doug may undesratnd the tradeoffs here a bit better.  But as far as I can tell, there would be a significant risk of standardizing something that's useless in the long run.

The fundamental advantage of creating_async (if we can get it to work) is that its functionality seems basic enough that it's unlikely to become completely obsolete, even in the presence of more sophisticated tools.

Hans

> 
> > 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
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>