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

[Anthony Williams]

On 15/11/10 15:33, Howard Hinnant wrote:
> On Nov 15, 2010, at 8:57 AM, Anthony Williams wrote:
>
>>> 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.
>>
>> I appreciate that there is a cost. Personally, I think it's worth
>> it: introducing data races is a serious issue.
>
> Here is an attempt to quantify the cost:
>
> My best estimate is that for those platforms on the Itanium ABI
> (which Apple is one), current_exception() and rethrow_exception()
> will not make a copy of the referenced exception no matter what the
> standard says.

Ouch!

> And so this:
>
>> Worse, this code may be race free when compiled with one compiler
>> (e.g. MSVC 2010) and acquire a data race when recompiled with a
>> different compiler (e.g. gcc).
>
> is going to be true regardless of what we do.  The reason for me to
> make such a strong statement is that Apple (and I assume other
> platforms) regularly allow for applications and dynamic libraries to
> be migrated from one OS version to another without the need for
> recompilation.  We of course recompile our own code for new OS's, but
> not 3rd party dyld's and applications.
>
> Without a recompilation, the Itanium ABI literally does not have the
> information to copy the exception at the point of current_exception()
> and rethrow_exception().

OK.

> For such platforms to make such a change, I believe we would have to
> create two ABI's:  A C++03 ABI and a C++0x ABI, which could not be
> intermixed.  This would mean that an application could not move to
> C++0x until all of its dyld's moved, and those dyld's could not move
> until all of their dependent dyld's moved.  Ultimately you get down
> to the OS dyld's, which would all have to be supplied in both ABI's,
> effectively doubling the size of the OS.

I appreciate that if the data is not present in code compiled to the 
C++03 ABI then C++0x code can only depend on C++0x code. However, can't 
the ABI be made backwards compatible, so it remains compatible with the 
C++03 ABI **and** is compatible with the new C++0x ABI? This would avoid 
"doubling the size of the OS". Of course, it depends on the details.

> I do not believe that this is a migration strategy that many
> platforms are going to buy into.
>
> If platforms do not have a practical migration strategy, then they
> are just not going to migrate.  And then you've got another export.

Is there nothing else in C++0x that breaks the ABI? There are certainly 
a lot of language facilities that are not in C++03. Is Apple going to 
oppose any change that breaks the ABI?

> That is a very high cost with little or no benefit to the end user.

"Little or no benefit" is a value judgment. I place quite a high value 
on not generating data races when code is ported from one compiler to 
another.

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