C++ exceptions to abort spawned work?

[rhalbersma]

The Cilk-Plus language specification is silent about speculative / non-deterministic parallelism. In particular, it does not state whether C++ exceptions can abort spawned work.

The older Cilk++ specs explicitly ruled out such behavior:

"... throwing an exception does not abort existing children or siblings of the strand in which the exception is thrown; these strands will run normally to completion. This behavior may changein a future version of the Intel Cilk++ SDK."

But still, given the old roots of Cilk in the world of parallel chess, it would be nice to have some sort of abort-mechanism. In particular, the behavior of JCilk would be nice to have:

"JCilk extends the notion of abruptlycompletes to encompass the implicit aborting of any spawned sidecomputations along the path from the point where the exception isthrown to the point where it is caughtJCilk extends the notion of abruptlycompletes to encompass the implicit aborting of any spawned side computations along the path from the point where the exception isthrown to the point where it is caught."

Are there any technical obstacles from implementing such features in Cilk-Plus? Is any such speculative parallelism on the roadmap for the near future of Cilk-Plus?

Thanks!

Rein

[Pablo_H_Intel]

The obstacles to aborting C++ code are both technical and linguistic. There are few things more difficult than writing C++ code that is robust in the presence of exceptions. This difficulty is compounded ten-fold if the exception can occur asynchronously. For this reason, the C++ Standard committee chose not to define what happens if you throw an exception from a signal handler. In addition exceptions, especially asynchonous excpetions, get in the way of optimization. Java code is less susceptable to the problems because it does not have destructors and because it is not so focused on performance. Having had discussions with people who are intimately familiar with JCilk, it is not clear that the JCilk approach is the best approach even for Java.

We are unlikely to use the JCilk approach to speculation in Intel Cilk Plus. Sadly, I can't give a timeline for any kind of speculation in Intel Cilk Plus. I can say only that the omission of speculation in the current offeringwas neither an oversite nor (solely) an inability to implement it.

In the mean time, there are several polling techniques that can be used to explicitly return from a child (either normally or via an exception) if an abort is desired. The best approach probably depends on the specific application.

- Pablo

[rhalbersma]

Thanks for the quick response! It turns out that some MIT students already have implemented the native inlet/abort features from Cilk5 in Cilk++ (I missed this on Google because I for my earlier post I had searched for "speculative Cilk-Plus" rather than "speculative Cilk++") Parallel game tree search was indeed the application I was interested in.

http://courses.csail.mit.edu/6.884/spring10/projects/rmperez-gmalecha_presentation.pdf

http://courses.csail.mit.edu/6.884/spring10/projects/rmperez-gmalecha_paper.pdf

http://courses.csail.mit.edu/6.884/spring10/projects/rmperez-gmalecha.tar.bz2

Rein