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

[Caitlin Sadowski]

Hey all,

Any other thoughts on this? Can we commit the first patch?

Also, here a fresh copy of the first patch, which fixes a name changed
since the time I initially emailed it out.

Cheers,

Caitlin

On Fri, Jul 1, 2011 at 3:48 PM, Caitlin Sadowski <supertri at google.com> 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
> Cheers,
> Caitlin
> On Thu, Jun 30, 2011 at 5:57 PM, Caitlin Sadowski <supertri at google.com>
> wrote:
>>
>> The following is a proposal for a project we would like to contribute to
>> Clang. Feel free to discuss.
>> Cheers,
>> Caitlin Sadowski
>> Google & University of California at Santa Cruz
>>
>> 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.
>>
>>  1 #include "thread_annotations.h"
>>  2 #define GUARDED_BY(x) __attribute__((GUARDED_BY(x)))
>>  3 #define ACQUIRED_AFTER(x) __attribute__((ACQUIRED_AFTER(x)))
>>  4
>>  5 Mutex mu1;
>>  6 Mutex mu2 ACQUIRED_AFTER(mu1);
>>  7
>>  8 int x GUARDED_BY(mu1);
>>  9 int a GUARDED_BY(mu2);
>>  10
>>  11 void foo()
>>  12 {
>> 13   mu2.Lock();
>> 14   mu1.Lock();
>> 15   if (x > 2)
>> 16     a = x + 1;
>> 17   else
>> 18     a = x - 1;
>> 19   mu1.Unlock();
>> 20   mu2.Unlock();
>> 21 }
>>
>> Sample compiler output:
>> ex.cc: In function 'void foo()':
>> ex.cc:12: warning: Lock 'mu1' is acquired after lock 'mu2' (acquired at
>> line 14) but is annotated otherwise
>>
>> 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.
>>
>> Future Projects
>>
>> Once we have this core set of thread safety annotations implemented, we
>> have several directions for future work we would like to pursue. These
>> include supporting additional types of annotations. For example, we would
>> like to extend the system to support annotations for functions which only
>> touch thread-local data and atomic functions which always execute as if they
>> are not interleaved with operations of other threads. We would also like to
>> build an annotation inference system; this system would enable application
>> of the thread safety analysis to large amounts of legacy code.
>>
>> [1] C. Flanagan and S. N. Freund. Type-based race detection for Java. In
>> Programming Language Design and Implementation (PLDI), June 2000.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threadsafety_parsing_easyattrs_2.patch
Type: text/x-patch
Size: 16427 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110712/3b058e27/attachment.bin>