<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
TRA and the current thread safety checking seem to us to be different bike sheds, both of which are interesting. For more, see below.
<div><br>
<div>
<div>
<div>On Jun 24, 2013, at 2:19 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">On Fri, Jun 21, 2013 at 1:31 PM, Dean Sutherland <span dir="ltr"><<a href="mailto:dsutherland@cert.org" target="_blank" class="cremed">dsutherland@cert.org</a>></span> wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">It may, in fact, be possible to combine the capabilities of TRA and</span><br>
</div>
the current thread safety checking to produce something very<br>
interesting. Let's talk about it! But we believe that TRA offers<br>
sufficient benefits to warrant its inclusion as a feature in addition<br>
to the existing lock-based analysis. They're similiar in that they<br>
both deal with thread safety, but solve the problem in different ways.<br>
</blockquote>
<div><br>
</div>
<div>I will freely admit that I've not read all of this thread (it is *very* long, where possible brevity would be helpful to get a wider audience), I wanted to expand on the first email I sent to Aaron in response to this comment.</div>
<div><br>
</div>
<div><br>
</div>
<div>I think it is fundamentally important to approach contributing this type of work to clang as *incremental* improvements to the existing functionality. It would be very disruptive to the project to have a second analysis system surrounding thread safety.
I'm not saying that the existing functionality is perfect or must be exactly preserved, I'm just saying that you should propose new functionality via an incremental path from where we are today.</div>
</div>
</div>
</div>
</blockquote>
[SNIP]<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>I think these issues will (to a certain extent) be just as important as the concerns of basing this on sound academic research, and having a good theoretical model behind the analysis and diagnostics produced. As an example, I think one thing that is actively
hurting the community in understanding your proposal is trying to first get an existing community to shift terminology to that of specific research papers, and then describing what you want in those terms. Maybe it would be possible to instead use the existing
terminology, or where it isn't good terminology correct the terminology of the existing system before trying to describe new things in terms of it?</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>The single biggest difference between the existing lock analysis and<br>
thread role analysis is that we're addressing different (but<br>
partly-overlapping) issues.<br>
<br>
Lock analysis starts with some data that must be protected from<br>
multi-threaded access. You then annotate the data to indicate the<br>
specific lock that protects it, annotate methods to indicate how they<br>
interact with the locks. Analysis involves tracking data references<br>
(which is the really hard part!) and then running the lock-set algorithm<br>
to make sure you never have an unprotected access. This is great stuff!<br>
This ensures that a program has correct and consistent use of locks and<br>
protection of data.<br>
<br>
Thread role analysis operates on policy models such as "Only the GUI<br>
event thread may invoke [long-list-of-methods]." This is a common<br>
idiom in many widely-used frameworks, for example AppKit's policy<br>
of always operating from the primary thread. Many of these policies exist<br>
because fine-grained locking was too difficult, too expensive, or even<br>
impossible—perhaps due to deadlock potential—for the problem at hand.<br>
Other frameworks use a "no concurrency" model, outsourcing concurrency from<br>
the application to the framework. Although this serves to provide thread<br>
confinement of data, it also places restrictions on what *functions* may be<br>
invoked, independent of the *data* those objects may touch. For example: such<br>
code may never start a thread running, grab a thread from a pool, etc. The</div>
<div>Actor design pattern provides an example of the "no concurrency in the </div>
<div>client" approach.</div>
<div><br>
Obviously, these two analyses are related. Policy-based concurrency<br>
sometimes serves as a proxy for lock-based concurrency. But policy-based<br>
concurrency is a subset of the use-case for TRA. When programmers know<br>
which thread roles may execute a particular function, this provides<br>
some guidance regarding what they can or should invoke from that<br>
function. For example, an astronomy application we analyzed<br>
compartmentalized things like computation, printing, disk and network i/o,<br>
etc. onto individual threads. This separation was partly for GUI<br>
responsiveness, performance and maintenance, all of which has limited<br>
relation to locking. The thread roles were purely a useful abstraction for<br>
enforcing developer policy.<br>
<br>
We feel that TRA and lock-based analysis are complementary, but<br>
different, systems that can benefit from each other. There's nothing<br>
inherently disruptive about TRA to the overall architecture of clang<br>
(it's mostly making use of existing mechanisms); it can be implemented<br>
in an incremental fashion for easier community involvement.<br>
Ultimately, we believe there are considerable benefits to integrating<br>
the two systems together, but there does not appear to be enough similarity<br>
to attempt to use the existing lock-based infrastructure as a jumping-off<br>
point.</div>
<div><br>
</div>
<div>Dean Sutherland</div>
<div>(with much help from Aaron Ballman)</div>
<br>
</div>
</div>
</body>
</html>