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

[Craig, Ben via cfe-dev]

On 7/21/2016 12:54 PM, Richard Smith wrote:
> On Wed, Jul 20, 2016 at 12:43 PM, Craig, Ben via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     C++14 6.7 Declaration statement, clause 4 has the standardese for
>     "Magic" / thread-safe statics. Footnote 91 says "The
>     implementation must not introduce any deadlock around execution of
>     the initializer."  I believe this is unimplementable.
>
>
> While your interpretation is not unreasonable, I believe you've 
> misunderstood the meaning and intent of this footnote. Note that it 
> says *the implementation* must not introduce any deadlock -- that is, 
> there must not be any deadlock that is not implied by the program 
> semantics. The normative sentence preceding this footnote says "If 
> control enters the declaration concurrently while the variable is 
> being initialized, the concurrent execution shall wait for completion 
> of the initialization." The potential for deadlock in that rule is not 
> affected by the presence of this footnote, because that's deadlock 
> introduced by the language semantics, not deadlock introduced by the 
> implementation.
>
> To understand the purpose of this footnote, you need to look at how 
> GCC 3.x implemented thread-safe local statics (prior to 
> standardization). They had a single, global, recursive mutex 
> protecting all local static initialization. This results in deadlock 
> *introduced by the implementation* if a static local variable's 
> initializer spawns and joins a thread, and that thread triggers 
> initialization of a different static local variable. It is 
> specifically that implementation strategy which is being called out as 
> non-conforming here.


Thanks for the clear explanation.  Would it be possible to tack on a few 
more words onto that footnote to clear that up?  My mistake reading of 
that note was basically "No deadlocks allowed", when my reading of the 
text should have been "No deadlocks allowed beyond the ones we just 
mandated".

Perhaps...
"The implementation must not introduce any deadlocks around execution of 
the initializer that are not implied by the program semantics".
Maybe the redundancy is against the C++ standards style, but it would 
make it a bit more obvious to readers of the spec that some deadlocks 
are not only possible, but required.

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160721/afb1b6ad/attachment.html>