[cpp-threads] Asynchronous Function Proposal

[Doug Lea]

Pablo Halpern wrote:
> 
> 1) The true argument for stealing continuations is space, not time. 
> I.e., we can support ``for(i=1 to 109) cilk_spawn f();'' without running 
> out of space.

At the risk of pushing this discussion even further off-course:
As implied in a previous post, I've come to a sour-grapes
position about this. Notice that this issue is nearly the same
as that of providing guaranteed tail-recursion support. That is,
without such guarantees, a recursive sequential version of such
a loop might run out of stack space; and even with guarantees,
user code that is not purely tail-recursive might do so.
While it is great to guarantee space bounds, C++/Java
programmers are also accustomed to avoiding recursive
constructions that encounter stack blow-ups for sequential
constructions, and could probably learn them for parallel
ones. The current Java ForkJoin, C++ TBB, and .Net TPL
mechanics for avoiding space blow-ups only in those cases
where they may become practical problems are not very pleasant;
perhaps arguing for better support by development tools.
(Or creating new languages such as cilk++).

>>   
> Thread-local variables certainly don't play well with Cilk threads.  We 
> have several ideas floating around at Cilk Arts for how to create 
> something that works better than TLS.  As we've explored parallelism in 
> general, we've come to see that TLS has the same problem as global 
> variables.  Tying a variable to a thread only works for very limited 
> scopes.  The problem is not limited to Cilk-style work-stealing.  Any 
> time a single job can be divided among threads, TLS falls apart.  This 
> can happen even in a do-it-yourself threading system with a sequential 
> job: the job queues a sub-task onto the task queue, when the sub-task 
> completes, it queues the next sub-task, which may be run on a different 
> worker thread (with different TLS).

Right. We hear about such issues all the time with the
Java medium-grained Executor framework, and probably
will hear even more with the lighter-weight Java7 support.
As much as we try to clarify the difference between a "task"
versus a "thread", some people still want all the advantages
of both without the disadvantages of either.
There are even web frameworks that
allocate nearly all objects as thread locals, so they can
equate session-state with thread-state.
Which is a cool hack but runs into serious problems when
they also try to add some task-based parallelism.
It would be nice to come up with APIs, tools, or whatever
that better guide people into more appropriate designs.
But as it stands, it is just too convenient for
developers to use TLS to maintain implicit parameters,
especially in web/enterprise middleware support for
transactions, authentication, etc.  The best we can
do for such users is provide before/after hooks in Executors
so that they can add and remove thread-locals on running
each task. As per previous discussions, this is
easier in Java since we don't have to cope with scoped
destructors.

-Doug