[cfe-dev] [cxxabi] Thread-safe statics causing deadlocks

[David Chisnall via cfe-dev]

On 20 Jul 2016, at 20:43, Craig, Ben via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> I'm not sure what should be done.  Removing the lock protections would be terrible.  Banning the use of locks in functions that construct statics would be terrible.  Banning the use of locks in functions called from static construction would be terrible.  It would be embarrassing to change the footnote in the standard to say that the language is permitted (even required) to introduce deadlocks.

Objective-C has a similar problem with the atomicity guarantees of +initialize.  The GCC runtime implementation held a global lock and ensured that only one thread could be running *any* initialiser at once.  The Apple and GNUstep implementations hold a per-class lock, which is far more prone to deadlock for precisely the same reasons as the C++ equivalent, yet yields a sufficiently large speedup for well-written code that users prefer it.

I believe that the text of the standard is fine, however.  The implementation does not introduce deadlocks, the user code introduces deadlocks.  When running code in a synchronised context, you must ensure that you perform the same lock-order checks as when running in any other synchronised context.  If users write code that contains deadlocks, then they should get deadlocks.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160721/76e001bc/attachment.bin>