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

Chris Lattner clattner at apple.com
Tue Jul 12 23:18:06 PDT 2011

On Jul 1, 2011, at 3:48 PM, Caitlin Sadowski wrote:

> Here is the first thread safety patch. Note that this patch depends on  prior refactoring patches I sent out. If you want to review it, you can go to:
> http://codereview.appspot.com/4667054

Hi Caitlin,

A few questions:

> Summary
> We would like to add a set of thread safety attributes to Clang. These attributes, based on a prior GCC implementation, will allow for checkable documentation of basic locking policies in multithreaded programs.  

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.

> Plan
> We are planning to re-implement the GCC thread safety attributes in Clang. We will submit a series of patches to the cfe-commits mailing list. Our current plan for this serie is as follows:
> 1) Basic parsing and semantic checking of the attributes which do not take arguments. In other words, checking whether the attribute is applied in the appropriate context (e.g. to a field, with no arguments).
> 2) Basic parsing and semantic checking of the attributes which do take arguments, but without parsing or checking the arguments themselves. At this point, we will simply discard the tokens making up the arguments. 
> 3) Attribute argument parsing.
> 4) Adding the thread safety analysis checks. We will teach the static analysis-based warnings layer to warn for violations of the annotations discussed on the links above. 

This sounds like a very reasonable breakdown.  Please start with #0 though, which is "gain consensus that this is a good thing to take into mainline" :)

I'm specifically concerned on a number of fronts here:

1. Are these annotations general enough to apply to many common lock-based APIs?
2. How do the annotations handle aliasing of lock objects?
3. How many bugs have been found in practice?
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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110712/d39247bf/attachment.html>

More information about the cfe-dev mailing list