blob: d9bf6d48c95c97fc5fa17a89f5706b1bd9e88df6 [file] [log] [blame]
Victor Costan70f81b0a7fe2018-01-31 23:09:501// Copyright (c) 2018 The Chromium Authors. All rights reserved.
2// Use of this source code is governed by a BSD-style license that can be
3// found in the LICENSE file.
4
5// This header file contains macro definitions for thread safety annotations
6// that allow developers to document the locking policies of multi-threaded
7// code. The annotations can also help program analysis tools to identify
8// potential thread safety issues.
9//
10// Note that the annotations we use are described as deprecated in the Clang
11// documentation, linked below. E.g. we use EXCLUSIVE_LOCKS_REQUIRED where the
12// Clang docs use REQUIRES.
13//
14// http://clang.llvm.org/docs/ThreadSafetyAnalysis.html
15//
16// We use the deprecated Clang annotations to match Abseil (relevant header
17// linked below) and its ecosystem of libraries. We will follow Abseil with
18// respect to upgrading to more modern annotations.
19//
20// https://github.com/abseil/abseil-cpp/blob/master/absl/base/thread_annotations.h
21//
22// These annotations are implemented using compiler attributes. Using the macros
23// defined here instead of raw attributes allow for portability and future
24// compatibility.
25//
26// When referring to mutexes in the arguments of the attributes, you should
27// use variable names or more complex expressions (e.g. my_object->mutex_)
28// that evaluate to a concrete mutex object whenever possible. If the mutex
29// you want to refer to is not in scope, you may use a member pointer
30// (e.g. &MyClass::mutex_) to refer to a mutex in some (unknown) object.
31
Lukasz Anforowicz5e71bd42018-09-17 19:28:5732#ifndef BASE_THREAD_ANNOTATIONS_H_
33#define BASE_THREAD_ANNOTATIONS_H_
Victor Costan70f81b0a7fe2018-01-31 23:09:5034
Lukasz Anforowicz5e71bd42018-09-17 19:28:5735#include "build/build_config.h"
36
37// TODO(lukasza): https://crbug.com/881875#c9: Enable lock annotations on Mac
38// after the clang bug is fixed: https://bugs.llvm.org/show_bug.cgi?id=38896
39#if defined(__clang__) && !defined(OS_MACOSX)
Victor Costan70f81b0a7fe2018-01-31 23:09:5040#define THREAD_ANNOTATION_ATTRIBUTE__(x) __attribute__((x))
41#else
42#define THREAD_ANNOTATION_ATTRIBUTE__(x) // no-op
43#endif
44
45// GUARDED_BY()
46//
47// Documents if a shared field or global variable needs to be protected by a
48// mutex. GUARDED_BY() allows the user to specify a particular mutex that
49// should be held when accessing the annotated variable.
50//
51// Example:
52//
53// Mutex mu;
54// int p1 GUARDED_BY(mu);
55#define GUARDED_BY(x) THREAD_ANNOTATION_ATTRIBUTE__(guarded_by(x))
56
57// PT_GUARDED_BY()
58//
59// Documents if the memory location pointed to by a pointer should be guarded
60// by a mutex when dereferencing the pointer.
61//
62// Example:
63// Mutex mu;
64// int *p1 PT_GUARDED_BY(mu);
65//
66// Note that a pointer variable to a shared memory location could itself be a
67// shared variable.
68//
69// Example:
70//
71// // `q`, guarded by `mu1`, points to a shared memory location that is
72// // guarded by `mu2`:
73// int *q GUARDED_BY(mu1) PT_GUARDED_BY(mu2);
74#define PT_GUARDED_BY(x) THREAD_ANNOTATION_ATTRIBUTE__(pt_guarded_by(x))
75
76// ACQUIRED_AFTER() / ACQUIRED_BEFORE()
77//
78// Documents the acquisition order between locks that can be held
79// simultaneously by a thread. For any two locks that need to be annotated
80// to establish an acquisition order, only one of them needs the annotation.
81// (i.e. You don't have to annotate both locks with both ACQUIRED_AFTER
82// and ACQUIRED_BEFORE.)
83//
84// Example:
85//
86// Mutex m1;
87// Mutex m2 ACQUIRED_AFTER(m1);
88#define ACQUIRED_AFTER(...) \
89 THREAD_ANNOTATION_ATTRIBUTE__(acquired_after(__VA_ARGS__))
90
91#define ACQUIRED_BEFORE(...) \
92 THREAD_ANNOTATION_ATTRIBUTE__(acquired_before(__VA_ARGS__))
93
94// EXCLUSIVE_LOCKS_REQUIRED() / SHARED_LOCKS_REQUIRED()
95//
96// Documents a function that expects a mutex to be held prior to entry.
97// The mutex is expected to be held both on entry to, and exit from, the
98// function.
99//
100// Example:
101//
102// Mutex mu1, mu2;
103// int a GUARDED_BY(mu1);
104// int b GUARDED_BY(mu2);
105//
106// void foo() EXCLUSIVE_LOCKS_REQUIRED(mu1, mu2) { ... };
107#define EXCLUSIVE_LOCKS_REQUIRED(...) \
108 THREAD_ANNOTATION_ATTRIBUTE__(exclusive_locks_required(__VA_ARGS__))
109
110#define SHARED_LOCKS_REQUIRED(...) \
111 THREAD_ANNOTATION_ATTRIBUTE__(shared_locks_required(__VA_ARGS__))
112
113// LOCKS_EXCLUDED()
114//
115// Documents the locks acquired in the body of the function. These locks
116// cannot be held when calling this function (as Abseil's `Mutex` locks are
117// non-reentrant).
118#define LOCKS_EXCLUDED(...) \
119 THREAD_ANNOTATION_ATTRIBUTE__(locks_excluded(__VA_ARGS__))
120
121// LOCK_RETURNED()
122//
123// Documents a function that returns a mutex without acquiring it. For example,
124// a public getter method that returns a pointer to a private mutex should
125// be annotated with LOCK_RETURNED.
126#define LOCK_RETURNED(x) THREAD_ANNOTATION_ATTRIBUTE__(lock_returned(x))
127
128// LOCKABLE
129//
130// Documents if a class/type is a lockable type (such as the `Mutex` class).
131#define LOCKABLE THREAD_ANNOTATION_ATTRIBUTE__(lockable)
132
133// SCOPED_LOCKABLE
134//
135// Documents if a class does RAII locking (such as the `MutexLock` class).
136// The constructor should use `LOCK_FUNCTION()` to specify the mutex that is
137// acquired, and the destructor should use `UNLOCK_FUNCTION()` with no
138// arguments; the analysis will assume that the destructor unlocks whatever the
139// constructor locked.
140#define SCOPED_LOCKABLE THREAD_ANNOTATION_ATTRIBUTE__(scoped_lockable)
141
142// EXCLUSIVE_LOCK_FUNCTION()
143//
144// Documents functions that acquire a lock in the body of a function, and do
145// not release it.
146#define EXCLUSIVE_LOCK_FUNCTION(...) \
147 THREAD_ANNOTATION_ATTRIBUTE__(exclusive_lock_function(__VA_ARGS__))
148
149// SHARED_LOCK_FUNCTION()
150//
151// Documents functions that acquire a shared (reader) lock in the body of a
152// function, and do not release it.
153#define SHARED_LOCK_FUNCTION(...) \
154 THREAD_ANNOTATION_ATTRIBUTE__(shared_lock_function(__VA_ARGS__))
155
156// UNLOCK_FUNCTION()
157//
158// Documents functions that expect a lock to be held on entry to the function,
159// and release it in the body of the function.
160#define UNLOCK_FUNCTION(...) \
161 THREAD_ANNOTATION_ATTRIBUTE__(unlock_function(__VA_ARGS__))
162
163// EXCLUSIVE_TRYLOCK_FUNCTION() / SHARED_TRYLOCK_FUNCTION()
164//
165// Documents functions that try to acquire a lock, and return success or failure
166// (or a non-boolean value that can be interpreted as a boolean).
167// The first argument should be `true` for functions that return `true` on
168// success, or `false` for functions that return `false` on success. The second
169// argument specifies the mutex that is locked on success. If unspecified, this
170// mutex is assumed to be `this`.
171#define EXCLUSIVE_TRYLOCK_FUNCTION(...) \
172 THREAD_ANNOTATION_ATTRIBUTE__(exclusive_trylock_function(__VA_ARGS__))
173
174#define SHARED_TRYLOCK_FUNCTION(...) \
175 THREAD_ANNOTATION_ATTRIBUTE__(shared_trylock_function(__VA_ARGS__))
176
177// ASSERT_EXCLUSIVE_LOCK() / ASSERT_SHARED_LOCK()
178//
179// Documents functions that dynamically check to see if a lock is held, and fail
180// if it is not held.
181#define ASSERT_EXCLUSIVE_LOCK(...) \
182 THREAD_ANNOTATION_ATTRIBUTE__(assert_exclusive_lock(__VA_ARGS__))
183
184#define ASSERT_SHARED_LOCK(...) \
185 THREAD_ANNOTATION_ATTRIBUTE__(assert_shared_lock(__VA_ARGS__))
186
187// NO_THREAD_SAFETY_ANALYSIS
188//
189// Turns off thread safety checking within the body of a particular function.
190// This annotation is used to mark functions that are known to be correct, but
191// the locking behavior is more complicated than the analyzer can handle.
192#define NO_THREAD_SAFETY_ANALYSIS \
193 THREAD_ANNOTATION_ATTRIBUTE__(no_thread_safety_analysis)
194
195//------------------------------------------------------------------------------
196// Tool-Supplied Annotations
197//------------------------------------------------------------------------------
198
199// TS_UNCHECKED should be placed around lock expressions that are not valid
200// C++ syntax, but which are present for documentation purposes. These
201// annotations will be ignored by the analysis.
202#define TS_UNCHECKED(x) ""
203
204// TS_FIXME is used to mark lock expressions that are not valid C++ syntax.
205// It is used by automated tools to mark and disable invalid expressions.
206// The annotation should either be fixed, or changed to TS_UNCHECKED.
207#define TS_FIXME(x) ""
208
209// Like NO_THREAD_SAFETY_ANALYSIS, this turns off checking within the body of
210// a particular function. However, this attribute is used to mark functions
211// that are incorrect and need to be fixed. It is used by automated tools to
212// avoid breaking the build when the analysis is updated.
213// Code owners are expected to eventually fix the routine.
214#define NO_THREAD_SAFETY_ANALYSIS_FIXME NO_THREAD_SAFETY_ANALYSIS
215
216// Similar to NO_THREAD_SAFETY_ANALYSIS_FIXME, this macro marks a GUARDED_BY
217// annotation that needs to be fixed, because it is producing thread safety
218// warning. It disables the GUARDED_BY.
219#define GUARDED_BY_FIXME(x)
220
221// Disables warnings for a single read operation. This can be used to avoid
222// warnings when it is known that the read is not actually involved in a race,
223// but the compiler cannot confirm that.
224#define TS_UNCHECKED_READ(x) thread_safety_analysis::ts_unchecked_read(x)
225
226namespace thread_safety_analysis {
227
228// Takes a reference to a guarded data member, and returns an unguarded
229// reference.
230template <typename T>
231inline const T& ts_unchecked_read(const T& v) NO_THREAD_SAFETY_ANALYSIS {
232 return v;
233}
234
235template <typename T>
236inline T& ts_unchecked_read(T& v) NO_THREAD_SAFETY_ANALYSIS {
237 return v;
238}
239
240} // namespace thread_safety_analysis
241
Lukasz Anforowicz5e71bd42018-09-17 19:28:57242#endif // BASE_THREAD_ANNOTATIONS_H_