[cfe-dev] Proposal for thread safety attributes for Clang

[Caitlin Sadowski]

Chris,

Any additional thoughts/questions?

Cheers,

Caitlin

On Thu, Jul 14, 2011 at 3:09 PM, Caitlin Sadowski <supertri at google.com> wrote:
> Chris,
>
>> Are these in mainline GCC or just a branch?  If they are in mainline GCC and
>> have shipped in a release, then taking them into Clang makes sense for
>> compatibility reasons.  If they are a research project that is in
>> development, then the bar to getting it into mainline clang is much higher,
>> because adding attributes is tantamount to a language extension.
>
> These annotations are in between the two extremes listed above. They
> have gone beyond the initial research project stage, as they have
> multiple years of use in production code.
>
> They are currently not in mainline GCC (they are in a full-fledged
> development branch). However, the only reasons for not including the
> annotations in mainline GCC are the result of implementation concerns:
> the GCC implementation involves invasive changes throughout the GCC
> parser and depends on specific details of the lowering to GIMPLE. The
> general consensus seems to be that the annotation system should be in
> mainline GCC, after changing how they are implemented (unless Clang
> gets there first).
>
>> I'm specifically concerned on a number of fronts here:
>> 1. Are these annotations general enough to apply to many common lock-based
>> APIs?
>
> The annotations themselves are general enough (the paper I cited
> earlier actually contains an entire sound type-system based on a
> subset of these annotations). Within the implementation, there are
> tricky cases (like aliasing of lock objects) that lead to difficulties
> in the application. However, our core synchronization libraries have
> been successfully annotated, and it looks like less than 15% of
> annotated code is impacted by these limitations.
>
>> 2. How do the annotations handle aliasing of lock objects?
>
> Right now they do not handle this. However, we would like eventually
> support this feature.
>
>> 3. How many bugs have been found in practice?
>
> In a (relatively small) subsection of code at Google that has thread
> safety annotations, I looked at one month of commit activity and found
> 18 bug-fixing commits (not including commits which just fix the
> annotations) that cited these annotations explicitly as the way the
> bug was found.
>
> Also, the thread safety annotations are useful beyond just bug fixing.
> At Google, the web search frontend team refused to write multithreaded
> code until these thread-safety warnings were made available (through
> that GCC branch) due to the number of bugs and difficulty of tracking
> them down.
>
>> 4. Have you considered doing this as a static analysis (where the bar is
>> much lower to get things into mainline) instead of as a language change?
>
> The attribute system and the most fundamental analyses are things we
> would like to see in the main compiler (after years of experience
> successfully using these annotations in GCC). Plus, having this
> starting point checked in will make it easier to build off and improve
> the analysis. We are planning to have future analyses that build off
> of these foundations start in the static analzyer.
>
> Cheers,
>
> Caitlin
>