<table><tr><td style="">aaronpuchert added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D22182">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D22182#490532" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D22182#490532</a>, <a href="https://phabricator.kde.org/p/mswan/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@mswan</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>Interesting. I have experimented with this a bit and I cannot find a way to articulate to the thread safety system that my lock and unlock functions are idempotent. If I call <tt style="background: #ebebeb; font-size: 13px;">lock.unlock()</tt> and later return without locking it again, I get a warning (or rather an error because I set <tt style="background: #ebebeb; font-size: 13px;">-Werror=thread-safety</tt>) that complains that I am releasing a lock that isn't held. So would <tt style="background: #ebebeb; font-size: 13px;">-Wno-error=thread-safety-negative</tt> allow us to get around that or is there possibly some other solution?</p></div>
</blockquote>

<p>Lock and unlock shouldn't be idempotent. There are <a href="https://en.wikipedia.org/wiki/Reentrant_mutex" class="remarkup-link" target="_blank" rel="noreferrer">recursive/reentrant mutexes</a>, which can be locked multiple times, but must be unlocked the same number of times. They are rarely needed though, do we want that here?</p>

<p>If you assume the lock is initially held, and want to return with the lock released, you need to annotate the function with <tt style="background: #ebebeb; font-size: 13px;">__attribute__((release_capability(lock)))</tt>.</p>

<p>I'm just having a lock at the DUChain locking and try to figure out what the best way would be. It's a bit of a problem that we're not exactly doing it "by the book" sometimes, such as when scoped locks are handed as parameters to functions. But there is usually a way around that.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D22182">https://phabricator.kde.org/D22182</a></div></div><br /><div><strong>To: </strong>mswan, KDevelop<br /><strong>Cc: </strong>aaronpuchert, kdevelop-devel, hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd<br /></div>