<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#492087" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">D22182#492087</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>The workaround being that we eliminate the try-lock behaviour in our locker constructors and move that timeout behaviour elsewhere?</p></div>
</blockquote>
<p>Exactly.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>That's not what we want there, we want an annotation on the function <tt style="background: #ebebeb; font-size: 13px;">REQUIRES_SHARED(...)</tt>. Remember that the main purpose of scoped locks is to ensure release on all code paths. If you don't want to release anything, there is no reason for a scoped lock.</p></blockquote>
<p>Err, so now I'm confused again. So, does <tt style="background: #ebebeb; font-size: 13px;">REQUIRES_SHARED(...)</tt> require that <strong>this share</strong> of the lock is no longer held upon completion of this function? If so then is it possible to annotate a function in a semantically identical way to <tt style="background: #ebebeb; font-size: 13px;">ENSURE_CAN_READ</tt> which implies that a read (i.e. shared) lock is held before and (possibly) after the function evaluates, or does that kind of behaviour break this whole thing? I imagine then we would have to be much more fine-grained with our usage of DUChain locks and move these lockers closer to the actual mutations to DUChain.</p></blockquote>
<p>Maybe the terminology is a bit confusing: a "shared" lock is a read lock (many readers can happily coexist), while an "exclusive" lock is a write lock. (The "exclusive" is omitted from the attributes because standard mutexes are always exclusive.) The annotation <tt style="background: #ebebeb; font-size: 13px;">REQUIRES_SHARED(m)</tt> means that the function can only be called when <tt style="background: #ebebeb; font-size: 13px;">m</tt> is held. Also, <tt style="background: #ebebeb; font-size: 13px;">m</tt> should still be held a the end of the function. Basically the attributes encode state transitions:</p>
<div class="remarkup-table-wrap"><table style="border-collapse: separate;
border-spacing: 1px;
background: #d3d3d3;
margin: 12px 0;">
<tr><td style="background: #ffffff;
padding: 3px 6px;"></td><td style="background: #ffffff;
padding: 3px 6px;">unlocked</td><td style="background: #ffffff;
padding: 3px 6px;">locked exclusive</td><td style="background: #ffffff;
padding: 3px 6px;">locked shared</td></tr>
<tr><td style="background: #ffffff;
padding: 3px 6px;">unlocked/unknown</td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">EXCLUDES</tt></td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">ACQUIRE</tt></td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">ACQUIRE_SHARED</tt></td></tr>
<tr><td style="background: #ffffff;
padding: 3px 6px;">locked exclusive</td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">RELEASE</tt></td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">REQUIRES</tt></td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">RELEASE</tt> + <tt style="background: #ebebeb; font-size: 13px;">ACQUIRE_SHARED</tt></td></tr>
<tr><td style="background: #ffffff;
padding: 3px 6px;">locked shared</td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">RELEASE_SHARED</tt></td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">RELEASE_SHARED</tt> + <tt style="background: #ebebeb; font-size: 13px;">ACQUIRE</tt></td><td style="background: #ffffff;
padding: 3px 6px;"><tt style="background: #ebebeb; font-size: 13px;">REQUIRES_SHARED</tt></td></tr>
<tr></tr>
</table></div>
<p>where the rows are the state of a mutex at the beginning of a function, and the columns are the state at the end of the function.</p>
<p>So if a function doesn't lock or unlock and just calls <tt style="background: #ebebeb; font-size: 13px;">ENSURE_CAN_READ</tt>, it's a hot candidate for <tt style="background: #ebebeb; font-size: 13px;">REQUIRES_SHARED</tt>. If we can fix all thread safety warnings and turn them on as errors, we might be able to remove these <tt style="background: #ebebeb; font-size: 13px;">ENSURE_*</tt> assertions completely, because we enforce that at compile-time.</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>