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

[Richard Smith via cfe-dev]

On Thu, Jul 21, 2016 at 1:27 PM, Craig, Ben <ben.craig at codeaurora.org>
wrote:

> 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> 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.
>

Perhaps we could simply remove the footnote, if it's creating confusion
rather than removing it. If you file an editorial issue at
github.com/cplusplus/draft/issues, I or one of the other maintainers of the
C++ draft will look into rewording or removing this. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160721/15092d91/attachment.html>