<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 21, 2016 at 1:27 PM, Craig, Ben <span dir="ltr"><<a href="mailto:ben.craig@codeaurora.org" target="_blank">ben.craig@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    On 7/21/2016 12:54 PM, Richard Smith wrote:<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Wed, Jul 20, 2016 at 12:43 PM,
            Craig, Ben via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <p>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.</p>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>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.</div>
            <div><br>
            </div>
            <div>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.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br></span>
    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".<br>
    <br>
    Perhaps...<br>
    "The implementation must not introduce any deadlocks around
    execution of the initializer that are not implied by the program
    semantics".<br>
    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.</div></blockquote><div><br></div><div>Perhaps we could simply remove the footnote, if it's creating confusion rather than removing it. If you file an editorial issue at <a href="http://github.com/cplusplus/draft/issues">github.com/cplusplus/draft/issues</a>, I or one of the other maintainers of the C++ draft will look into rewording or removing this. Thanks!</div></div></div></div>