diff options
| -rw-r--r-- | Documentation/memory-barriers.txt | 44 |
1 files changed, 44 insertions, 0 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 70a09f8a0383..a10f7cd2619e 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt | |||
| @@ -269,6 +269,50 @@ And there are a number of things that _must_ or _must_not_ be assumed: | |||
| 269 | STORE *(A + 4) = Y; STORE *A = X; | 269 | STORE *(A + 4) = Y; STORE *A = X; |
| 270 | STORE {*A, *(A + 4) } = {X, Y}; | 270 | STORE {*A, *(A + 4) } = {X, Y}; |
| 271 | 271 | ||
| 272 | And there are anti-guarantees: | ||
| 273 | |||
| 274 | (*) These guarantees do not apply to bitfields, because compilers often | ||
| 275 | generate code to modify these using non-atomic read-modify-write | ||
| 276 | sequences. Do not attempt to use bitfields to synchronize parallel | ||
| 277 | algorithms. | ||
| 278 | |||
| 279 | (*) Even in cases where bitfields are protected by locks, all fields | ||
| 280 | in a given bitfield must be protected by one lock. If two fields | ||
| 281 | in a given bitfield are protected by different locks, the compiler's | ||
| 282 | non-atomic read-modify-write sequences can cause an update to one | ||
| 283 | field to corrupt the value of an adjacent field. | ||
| 284 | |||
| 285 | (*) These guarantees apply only to properly aligned and sized scalar | ||
| 286 | variables. "Properly sized" currently means variables that are | ||
| 287 | the same size as "char", "short", "int" and "long". "Properly | ||
| 288 | aligned" means the natural alignment, thus no constraints for | ||
| 289 | "char", two-byte alignment for "short", four-byte alignment for | ||
| 290 | "int", and either four-byte or eight-byte alignment for "long", | ||
| 291 | on 32-bit and 64-bit systems, respectively. Note that these | ||
| 292 | guarantees were introduced into the C11 standard, so beware when | ||
| 293 | using older pre-C11 compilers (for example, gcc 4.6). The portion | ||
| 294 | of the standard containing this guarantee is Section 3.14, which | ||
| 295 | defines "memory location" as follows: | ||
| 296 | |||
| 297 | memory location | ||
| 298 | either an object of scalar type, or a maximal sequence | ||
| 299 | of adjacent bit-fields all having nonzero width | ||
| 300 | |||
| 301 | NOTE 1: Two threads of execution can update and access | ||
| 302 | separate memory locations without interfering with | ||
| 303 | each other. | ||
| 304 | |||
| 305 | NOTE 2: A bit-field and an adjacent non-bit-field member | ||
| 306 | are in separate memory locations. The same applies | ||
| 307 | to two bit-fields, if one is declared inside a nested | ||
| 308 | structure declaration and the other is not, or if the two | ||
| 309 | are separated by a zero-length bit-field declaration, | ||
| 310 | or if they are separated by a non-bit-field member | ||
| 311 | declaration. It is not safe to concurrently update two | ||
| 312 | bit-fields in the same structure if all members declared | ||
| 313 | between them are also bit-fields, no matter what the | ||
| 314 | sizes of those intervening bit-fields happen to be. | ||
| 315 | |||
| 272 | 316 | ||
| 273 | ========================= | 317 | ========================= |
| 274 | WHAT ARE MEMORY BARRIERS? | 318 | WHAT ARE MEMORY BARRIERS? |
