threads and C++ exceptions...
Kesavan Shanmugam
Are there any implications for using threads with C++ exceptions?
- Is exception handling more difficult to implement for a compiler
writer in the presence of threads?
- Do compilers (Sun/HP/Digital/SGI/IBM for example) support exception
handling in the presence of threads?
- Does the runtime cost of maintaining exception handling information
increase when you factor in threads?
If you have insight into these issues, please post the response to this
newsgroup or send mail to me at kesa...@i2.com
Thanks
K7
Dave Butenhof
Kesavan Shanmugam wrote:
> Are there any implications for using threads with C++ exceptions?
This question has come up before. I'll answer it anyway, but you might
also consider dredging Deja News archives of this newsgroup for additional
context.
> - Is exception handling more difficult to implement for a compiler
> writer in the presence of threads?
Depends on the compiler and system. It certainly doesn't HAVE to be any
more complicated. Except, of course, that the exception system itself must
be thread safe if it's going to work with threads.
> - Do compilers (Sun/HP/Digital/SGI/IBM for example) support exception
> handling in the presence of threads?
I don't have personal knowledge of the situation on HP, SGI, and IBM. I
know that the Solaris C++ supports object destructors on thread
cancellation, so my assumption has been that this means the compiler
supports "exception handling in the presence of threads". On the other
hand, there's no rule that object destructors actually be tied to the
implementation of exceptions, so that assumption may be incorrect.
On Digital UNIX, exceptions are provided for in the "calling standard"
architecture, and supported by the libexc library for use by any facility
with interest. In particular, DEC C++ uses libexc exceptions for both C++
exceptions and object destructors, while the thread library uses libexc
for cancellation and thread exit. Because libexc is thread safe, exception
handling and object destructors work perfectly in the presence of threads,
and C++ object destructors are executed when the thread is cancelled or
calls pthread_exit. (There's no way to "catch" cancellation or exit,
however, because the C++ runtime chooses to ignore all exceptions that
weren't raised by C++; however this could be supported if the C++
developers chose to invent some form of mapping of "system" exceptions
into special C++ objects, and there's been some discussion of the
possibility.)
> - Does the runtime cost of maintaining exception handling information
> increase when you factor in threads?
Again, this depends. The Digital UNIX libexc mechanism depends on
compiler-generated PC mapping information to deliver exceptions. Aside
from some data generated by the compiler and linker, there's no runtime
overhead until an exception is raised. Then it needs to walk the stack to
find active frames, and locate the relevant section of the PC map to
determine the proper disposition of an exception within each frame. The
current implementation of libexc creates an optimized cache of frame data,
rather than doing a binary search of the PC map each time, and of course
that cache must be synchronized when threads are present. That adds some
overhead, and some complication; but, again, there's no overhead until an
exception is raised.
/---------------------------[ Dave Butenhof ]--------------------------\
| Digital Equipment Corporation bute...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/