Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

Exceptions and TBB

eddie_breeveld1
Beginner
1,017 Views

I know that OpenMPcould nothandle processor exceptions outside the thread that the exception occurred in (I can see why). In other words, all exceptions must be handled inside each thread. How does TBB deal with exceptions?

I am particularly interested in floating point exceptions, which we need to trap, occurring inside array calculations. The array work is ideal for multi-threading, but can TBB deal sensibly with any exceptions that might occur, such as division by zero?

Eddie Breeveld

0 Kudos
3 Replies
Alexey-Kukanov
Employee
1,017 Views

Exception handling in TBB is one of questions we are carefully considering. For the moment, TBB does nothing to catch an exception happened inside a parallel algorithm. So if an exception happens for a TBB worker thread, it will not be handled. We are aware of this; unfortunately designing right solution for the problem is not that easy.

Ideally, once an exception happened, it should be propagated to the thread that called the corresponding parallel algorithm (the master thread) to be handled in the user application code, and all not-yet-started tasks belonging to this runningalgorithm should not start. And both parts are challenging. The exception caught in a worker thread should ideally be propagated unchanged; but how to transfer an exception variable of virtually any type between threads? It could be easily transferred just like a piece of memory of known size, but it needs to be re-raised in the master thread with its original type then - is there away to do that? The second part of the problem, cancellation of tasks, is also hard, mainly because there could be several algorithmslaunchedby several master threads all running at the same time, with their tasks mixed unpredictablyin task pools. Some applications could not run any high-level TBB algorithm at all, instead operating at task levels to implement their own algorithms. And all these can be nested one into another.

And after all, the solution should not much increase overhead added by the library, until an exception actually happens. Have I managed to give you a taste of complexity of the problem? :-)

0 Kudos
eddie_breeveld1
Beginner
1,017 Views

I thought there was a good reason! Thanks for your rapid response.

Is iteasier to propagate 'hardware' exceptions, such as floating point errors? (Probably not, but it is worth asking.)

0 Kudos
Alexey-Kukanov
Employee
1,017 Views

I think it is not easier with HW exceptions, because there is only one standard exception handling mechanism in C++, and exceptions only differ by variable type.

If you know the exact place in your algorithm where an exception can happen, and if you could repair after it without a need to stop further processing, I think you could catch and process exceptions inside your code executed by TBB, i.e. inside Body::operator() or task::execute(), instead of re-throwing it across threads.

0 Kudos
Reply