Home

Handling multiple concurrent exceptions in C++ using futures

Matti Rintala, Handling multiple concurrent exceptions in C++ using futures.

Aside from describing the way exceptions are handled in KC++, a concurrent C++ sytem based on active objects, this nice paper provides a short and readable description of the main difficulties in combining exceptions and asynchronous calls.

The KC++ approach is library based, and the paper explains how KC++ matches itself to the C++ exception handling model.

The description of the Ada model, in section 7, may be a bit unclear. Specifically, a nuance that is easy to overlook is that exceptions raised within an accept statement (and not handled there) are propagated both in the calling and in the called tasks. The Ada83 Rationale explains this in more detail and gives examples of use.

From an historical perspective it is a bit amusing (and also quite sad) that the issues resulting from the interaction of concurrency and exceptions, that the Ada designers had to tackle in late '70s early 80s, still occupy the time of language desginers today.

By Ehud Lamm at 2006-09-22 10:31 | Parallel/Distributed | other blogs | 37572 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

C++ is ugly

Relevant quotes:

When adding concurrency to an existing programming language (like C++), the exception handling mechanism has already been fixed, and the added concurrency features should be designed to be as compatible with the existing mechanism as possible. This unavoidably means some compromises to the elegance of the system.

KC++ exception handling is implemented using standard C++ and without modifying the C++exception model (and compiler) in any way. This means that KC++ exceptions have to cope with the restrictions caused by the C++exception model, which has been designed without thinking about issues caused by concurrency.

One problem with reduction functions and multiple exceptions is that C++ does not allow replacing a thrown exception before it has been caught in a catch clause. This means that reduction functions can freely choose a suitable exception only if reduction happens prior to throwing any exceptions. KC++ futures do this automatically by synchronising with their future group before throwing exceptions. For other situations KC++ provides a macro mechanism to catch an already thrown exception and perform necessary reduction.

Also, the paper doesn't explain how do they deal with the fact that the set of exception types recognized at a particular point must be known statically. In C++ it's impossible to catch an arbitrary exception, store it, and throw it somewhere else (e.g. in another thread). This is possible in most languages which support exceptions.

By Qrczak at Fri, 2006-09-22 15:40 | login or register to post comments

Catching, storing, throwing exceptions in C++

Since I'm the author of the article, I think I'm allowed to comment. :)

Yes, you are right that exception types must be know statically in C++. However, if you are willing to make some compromises instead of having completely "arbitrary exceptions", you can create a static metaprogramming mechanism for passing exceptions among threads. An article on that has just recently been published online in Software - Practice and Experience: DOI: 10.1002/spe.754 (and will soon appear in the paper). A preprint pdf can be found on my web page.

On Ada rendez-vous and propagating the exception in both tasks: Yes, I did not make this point clear in my original workshop article. An expanded version of the article will shortly appear as a chapter in a forthcoming Springer LNCS book "Advanced Topics in Exception Handling Techniques" (when the publishing process is over, I'll try to put a pdf version on my web page, if possible). This later version mentions that the exception propagates in both tasks.

Matti

By Matti Rintala at Fri, 2006-09-22 20:53 | login or register to post comments

From the other direction

Coming from the other direction, Jan Broenink and Dusko Jovanovic have explored how to add exception handling mechanisms to an existing concurrency framework in their paper On Issues of Constructing an Exception Handling Mechanism for CSP-Based Process-Oriented Concurrent Software. From the abstract:

This paper discusses issues, possibilities and existing approaches for fitting an exception handling mechanism (EHM) in CSP-based process-oriented software architectures. After giving a survey on properties desired for a concurrent EHM, specific problems and a few principal ideas for including exception handling facilities in CSP-designs are discussed. As one of the CSP-based frameworks for concurrent software, we extend CT (Communicating Threads) library with the exception handling facilities. The extensions result in two different EHM models whose compliance with the most important demands of concurrent EHMs (handling simultaneous exceptions, the mechanism formalization and efficient implementation) are observed.

Of course, some of the difficulties that Hilderink and Jovanic addressed are a result of the CSP-style rendezvous-based communications model they were working with. Erlang has had exception-handling for quite a while now. But even there, adding exception handling requires some careful thought, as this paper from the Erlang 2004 Workshop demonstrates.

By Allan McInnes at Fri, 2006-09-22 17:23 | login or register to post comments