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

[Douglas Gregor]

Hello Caitlin,

On Jun 30, 2011, at 5:57 PM, Caitlin Sadowski wrote:

> Thread Safety Attributes for Clang
> 
> 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.  
> 
> Background
> The synchronization policies in modern multithreaded code may be poorly documented, and incorrectly inferred by new developers. Furthermore, when these policies are improperly followed they often lead to bugs which are difficult to reproduce and diagnose. One strategy for avoiding concurrency bugs is formal documentation of these synchronization policies. By writing this documentation using attribute-based annotations, Clang can mechanically check and warn about issues that could potentially result in race conditions and deadlocks.
> 
> Example
> 
> A code sample which demonstrates two of the proposed annotations is below. In this code sample, variables are protected by locks from the Mutex class. This class has been annotated to specify the API used to lock and unlock.
> 
> * GUARDED_BY specifies a particular lock should be held when accessing the annotated variable. Violations of this locking policy may lead to data races. 
> *  ACQUIRED_AFTER annotations document the acquisition order between locks that can be held simultaneously by a thread, by specify the locks that need to be acquired before the annotated lock. Violations of this locking policy may lead to deadlocks.
> 
> [snip example]
> 
> Previous Work
> 
> As mentioned, thread safety annotations have been implemented in GCC. A full list of the annotations and descriptions for them can be found here:
> 
> http://gcc.gnu.org/wiki/ThreadSafetyAnnotation
> https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr
> 
> These annotations have been in active use in Google’s C++ codebase for a couple of years, so there is a large informal case study of their usefulness. The ideas behind many of these annotations come originally from a research paper [1].
> 
> 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. 


By "static analysis-based warnings layer" are you referring to Sema's CFG-base warnings, or a new checker for the static analyzer?

Sorry for the delayed response. This looks like an excellent addition to Clang. The attributes themselves appear general enough to apply to a wide range of locking APIs, so it's general enough to be useful, and I'm glad to hear that there's significant experience with these annotations in the GCC world. 

Your first patch is fine to commit, with one addition: please also provide documentation for the attributes you're adding (it's fine for it to be based on the text in the C/C++ Thread Safety Annotations doc. you link to above), which should go here:

	http://clang.llvm.org/docs/LanguageExtensions.html

in its own, new section. That way, we'll have a single point of reference on the Clang site for this feature, and it can be updated as you add more features.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110722/2c4670a4/attachment.html>