Lines Matching full:accesses

1 MARKING SHARED-MEMORY ACCESSES
5 normal accesses to shared memory, that is "normal" as in accesses that do
7 document these accesses, both with comments and with special assertions
17 1.	Plain C-language accesses (unmarked), for example, "a = b;"
33 Neither plain C-language accesses nor data_race() (#1 and #2 above) place
40 C-language accesses.  It is permissible to combine #2 and #3, for example,
45 C-language accesses, but marking all accesses involved in a given data
54 data_race() and even plain C-language accesses is preferable to
82 reads can enable better checking of the remaining accesses implementing
129 the other accesses to the relevant shared variables.  But please note
163 Use of Plain C-Language Accesses
166 Here are some example situations where plain C-language accesses should
169 1.	Accesses protected by mutual exclusion, including strict locking
172 2.	Initialization-time and cleanup-time accesses.	This covers a
203 Note that it is important to use plain C-language accesses in these cases,
211 It is important to comment marked accesses so that people reading your
213 However, it is even more important to comment plain C-language accesses
216 of how the compiler has been prevented from optimizing those accesses
280 the accesses to foo within both update_foo() and read_foo() can (and
281 should) be plain C-language accesses.  One benefit of making them be
282 plain C-language accesses is that KCSAN can detect any erroneous lockless
296 Alternatively, given that KCSAN is to ignore all accesses in this function,
315 conditionally trap on accesses.
343 Because foo is read locklessly, all accesses are marked.  The purpose
464 Because foo is accessed locklessly, all accesses are marked.  It does
510 are not supposed to be concurrent accesses during initialization.  The