|
72 | 72 | // member functions: |
73 | 73 | // v.load_relaxed() -> T |
74 | 74 | // v.load_acquire() -> T |
75 | | -// v.relaxed_store(x) -> void |
| 75 | +// v.store_relaxed(x) -> void |
76 | 76 | // v.release_store(x) -> void |
77 | 77 | // v.release_store_fence(x) -> void |
78 | 78 | // v.cmpxchg(x, y [, o]) -> T |
|
156 | 156 | // for testing for that are not provided. (There might have been some types on |
157 | 157 | // some platforms that used a lock long-ago, but that's no longer the case.) |
158 | 158 | // |
159 | | -// * Rather than load/store operations with a memory order parameter, |
160 | | -// Atomic<T> provides load_{relaxed,acquire}() and {relaxed,release}_store() |
161 | | -// operations, as well as release_store_fence(). |
| 159 | +// * Rather than load and store operations with a memory order parameter, |
| 160 | +// Atomic<T> provides load_relaxed(), load_acquire(), release_store(), |
| 161 | +// store_relaxed(), and release_store_fence() operations. |
162 | 162 | // |
163 | 163 | // * Atomic<T> doesn't provide operator overloads that perform various |
164 | 164 | // operations with sequentially consistent ordering semantics. The rationale |
@@ -266,7 +266,7 @@ class AtomicImpl::CommonCore { |
266 | 266 | return AtomicAccess::load_acquire(value_ptr()); |
267 | 267 | } |
268 | 268 |
|
269 | | - void relaxed_store(T value) { |
| 269 | + void store_relaxed(T value) { |
270 | 270 | AtomicAccess::store(value_ptr(), value); |
271 | 271 | } |
272 | 272 |
|
@@ -546,8 +546,8 @@ class AtomicImpl::Atomic<T, AtomicImpl::Category::Translated> |
546 | 546 | return recover(_value.load_acquire()); |
547 | 547 | } |
548 | 548 |
|
549 | | - void relaxed_store(T value) { |
550 | | - _value.relaxed_store(decay(value)); |
| 549 | + void store_relaxed(T value) { |
| 550 | + _value.store_relaxed(decay(value)); |
551 | 551 | } |
552 | 552 |
|
553 | 553 | void release_store(T value) { |
|
0 commit comments