[cfe-dev] [RFC] Adding Thread Role Analysis

[Chandler Carruth]

On Fri, Jun 21, 2013 at 1:31 PM, Dean Sutherland <dsutherland at cert.org>wrote:

> It may, in fact, be possible to combine the capabilities of TRA and
> the current thread safety checking to produce something very
> interesting.  Let's talk about it!  But we believe that TRA offers
> sufficient benefits to warrant its inclusion as a feature in addition
> to the existing lock-based analysis.  They're similiar in that they
> both deal with thread safety, but solve the problem in different ways.
>

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.


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.

This may include refactoring what we have today to make it more generic and
usable in both the static analyzer and the analysis based warnings, it may
include finding ways to incrementally add the necessary complexity and
features to the existing logic, and it may even include concerns over
deployment and how users can start benefitting from it.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130624/9fc5e876/attachment.html>