[cpp-threads] Asynchronous Function Proposal

Boehm, Hans hans.boehm at hp.com
Sun Jun 7 19:57:10 BST 2009


Thanks to Arch, Doug, and Pablo for the corrections.

It sounds to me like Lawrence's proposal fundamentally would work, with one highly desirable change:  We do need to give the implementation the necessary leeway to run an async task at the point of call, so that it can throttle the number of async tasks when it becomes necessary for space reasons.  Possibly this could be another policy option, though it sounds to me like the most useful policy is

run sequentially at point of creation (if we have too many pending tasks), or
run sequentially at point of request (if it didn't get stolen in the meantime), or
run in a separate thread.

It's unclear to me whether that means that exceptions should sometimes become visible at the point of async creation or not.  It may be that space-based throttling is rare enough that we can afford any extra overhead needed to defer the exception, though that's probably surprising in some cases.  Having to handle exception in two places also seems unfortunate.

Even if exceptions are handled only at the request point, we need to explicitly allow running the task earlier, since that's visible by other means.

I would still favor sticking with Lawrence's design that avoids (visibly) reusing threads for multiple tasks.  The issues with thread locals seem to me to be far more serious for C++ than Java.  On the other hand, it would be good to set things up so that we can easily add more policies later.  (I'm assuming that thread locals with arbitrary destructors are here to stay, though I think we now have strong arguments on both sides of that issue.)

A more minimalist approach may be to support only the fully_threaded policy for now, but leave room for additional policies in the future.

Hans


More information about the cpp-threads mailing list