[cpp-threads] Issue 1369 --- thread safety of std::rethrow_exception

[Boehm, Hans]

I'm a bit concerned that we're talking about a bunch of different things here.  I think the most worrisome scenario for this issue is a program that invokes a function with async() and then turns the result into a shared_future, and makes the result f available to multiple threads.  If the asynchronously run function throws an exception, then that exception e may be thrown in several different threads calling f.get().  If one of those threads modifies e, we have a data race.

I'm unclear about (a) why you would want to modify the exception, and (b) how common that is in practice.  Can someone enlighten me?  I normally think of exceptions as information that's read by the handler.  Is there another scenario that I'm missing?  Is there a common use case that we break?

The argument for this resolution is that it appears to be the only thing implementable in the Itanium ABI, which I believe is commonly used on other platforms, like X86-64.  Breaking the exception ABI seems like a very high cost, so I think we'd need at least a more solid example of breakage than I've seen so far.

(The issue of whether you want to pass exceptions between threads is different.  C++ certainly doesn't prevent you from handling exceptions locally, but I agree with Anthony that that's not always the right thing.)

Hans

-----Original Message-----
From: cpp-threads-bounces at decadent.org.uk [mailto:cpp-threads-bounces at decadent.org.uk] On Behalf Of Anthony Williams
Sent: Friday, November 12, 2010 5:27 AM
To: cpp-threads at decadent.org.uk
Subject: Re: [cpp-threads] Issue 1369 --- thread safety of std::rethrow_exception

On 12/11/10 12:18, N.M. Maclaren wrote:
> On Nov 12 2010, Anthony Williams wrote:
>>
>> I am very much concerned about the proposed resolution of this issue.
>> Prior to the introduction of std::exception_ptr it was never possible
>> to transfer exceptions between threads, and thread safety of exception
>> types was not an issue.
>
> It's FAR more serious than what is nowadays called 'thread safety'!
>
>> With the introduction of exception_ptr and rethrow_exception, it is
>> possible to transfer exceptions between threads. In itself, this is a
>> good thing. However, exceptions are not local. The code that handles
>> the exception may not know that this is an exception that has been
>> transferred.
>
> That's horrific! It is also a stake through the coffin (not just a nail)
> of any implementation that attempts to support system-generated exceptions
> as C++ exceptions, or even the cleanup of any system state during handlers.

This facility has been in the C++0x draft for a while now (it was in the
August 2007 working draft, N2369), and is now in at least two shipping
compilers: MSVC2010 and g++ 4.4 and later.

Just to avoid confusion: exceptions are only transferred between threads
if you explicitly capture them in an exception_ptr object either
directly or by wrapping a function in a packaged_task, and then
explicitly rethrow in another thread either with std::rethrow_exception,
or by calling some_future.get().

> The point is that genuine exceptions often include thread-specific data,
> often of a form that CANNOT be transferred between threads.

This issue (1369) proposes that rethrowing must always copy the
exception. This would therefore enable such implementations to copy the
appropriate data in the exception copy constructor.

> C++ doesn't support resumption, which is something that REALLY can't be
> done if you pass exceptions between threads, but what about cleanup of
> (say) attached GPUs? I am involved with a course where the students are
> being taught to use GPUs from C++, so it's a real-life problem. Passing
> exceptions between threads is a classic no-no - when I queried it at some
> WG21 meeting, I was told that it had been positively decided against.
>
> Please rethink. Forbidding that practice is the only sane solution.

I disagree; there are many uses for passing exceptions between threads.
In any case I seriously doubt the feature will be removed from C++0x at
this late stage.

Anthony
--
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++0x thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

--
cpp-threads mailing list
cpp-threads at decadent.org.uk
http://www.decadent.org.uk/cgi-bin/mailman/listinfo/cpp-threads