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

[Caitlin Sadowski]

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