|
25 | 25 | *Callers must beware that the macro argument may be evaluated multiple |
26 | 26 | *times! |
27 | 27 | * |
28 | | - *CAUTION: Care must be taken to ensure that loads and stores of |
29 | | - *shared memory values are not rearranged around spinlock acquire |
30 | | - *and release. This is done using the "volatile" qualifier: the C |
31 | | - *standard states that loads and stores of volatile objects cannot |
32 | | - *be rearranged *with respect to other volatile objects*. The |
33 | | - *spinlock is always written through a volatile pointer by the |
34 | | - *spinlock macros, but this is not sufficient by itself: code that |
35 | | - *protects shared data with a spinlock MUST reference that shared |
36 | | - *data through a volatile pointer. |
| 28 | + *Load and store operations in calling code are guaranteed not to be |
| 29 | + *reordered with respect to these operations, because they include a |
| 30 | + *compiler barrier. (Before PostgreSQL 9.5, callers needed to use a |
| 31 | + *volatile qualifier to access data protected by spinlocks.) |
37 | 32 | * |
38 | 33 | *Keep in mind the coding rule that spinlocks must not be held for more |
39 | 34 | *than a few instructions. In particular, we assume it is not possible |
|