search

habanero-rice / hclib

A C/C++ task-based programming model for shared memory and distributed parallel computing.
http://habanero-rice.github.io/hclib/
BSD 3-Clause "New" or "Revised" License
71 stars 35 forks source link

ESCAPING_ASYNC property not supported #8

Open DaoWen opened 8 years ago

DaoWen commented 8 years ago

We currently support "escaping" asyncs internally (they're used for our fiber-based finish-scope continuations), but the ESCAPING_ASYNC property does not seem to be supported through the user-facing API.

We should add support for "escaping" asyncs and/or remove the ESCAPING_ASYNC definition. (We don't have to implement this via a property.)

I recommend supporting "escaping" asyncs. Currently, apps that synchronize via DDTs rather than nested finish scopes see a significant amount of contention on the implicit top-level finish scope because very async has to check-in/out of that one finish scope. Using "escaping" asyncs removes this point of contention.

On a side note, I think "escape" might already have a set meaning in the literature, and I'm not sure if this usage conflicts (i.e., I may not have picked the best name for this, and we may want to revisit that topic).

agrippa commented 8 years ago

Ensuring we support escaping asyncs (and adding testing for that) sounds like a good step to me. What is the naming conflict on escape? I'm not familiar with any other meaning.

DaoWen commented 8 years ago

I had trouble finding the reference again when I was opening the issue earlier today, but I tracked it down again. See §3.1 in Work-First and Help-First Scheduling Policies for Async-Finish Task Parallelism.

agrippa commented 8 years ago

Gotcha. Finish-free asyncs? Unregistered asyncs? Floating asyncs? Any other ideas?

DaoWen commented 8 years ago

Scopeless? Unscoped? Independent? Meta? (i.e., an asynchronous async)

I like "meta" just because it's meta. I think "finish-free" is the most descriptive. I feel "unscoped" might be the best fit for an API, e.g., PROP_UNSCOPED or async_unscoped(...).

However, it wouldn't surprise me if I had a totally different viewpoint on this in the morning. As long as we don't pick something terrible, I think whatever we choose will grow on us and seem natural after a while.

agrippa commented 8 years ago

If you think finish-free is the most descriptive, I'd go with that one. If we're trying to avoid overloaded terms to begin with, it seems like we'd want to avoid a term as overloaded as "scope".

DaoWen commented 8 years ago

Good point. PROP_NO_FINISH or PROP_NO_FIN would work if we stick with using properties.

DaoWen commented 8 years ago

One thing that might be problematic with supporting finish-free asyncs is how they interact with our termination algorithm. I think it would be up to the user to properly synchronize at the top-level such that the implicit end finish in hclib_finalize does not complete until all the finish-free asyncs return. Since this is an "advanced" feature for optimization, I think that sounds like a reasonable requirement.