On Thu, 17 Jul 2025 18:00:31 GMT, Chen Liang <li...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>>
>>> 279: * <li>read write access modes for all {@code T}. On 32-bit platforms,
>>> access modes
>>> 280: * {@code get} and {@code set} for {@code long}, {@code double}
>>> and {@code MemorySegment}
>>> 281: * are supported but may be non-atomic, as described in Section
>>> {@jls 17.7}
>>
>> Suggestion:
>>
>> * are supported but may be non-atomic in the sense of Section {@jls
>> 17.7}
>>
>>
>> A useful taxonomy has atomic _read-modify-write_ operations (atomic updates,
>> numeric atomic updates, bitwise atomic updates, like CASes, etc.), and
>> atomic _access_ operations, that is, atomic loads and stores (atomic reads
>> and writes).
>>
>> But the reference to the JLS section here should clarify what is meant in
>> this specific context, namely access operation, not read-modify-write
>> operations.
>
> Yep, to distinguish access and the encapsulated read-modify-write atomicity,
> I decided to avoid using "atomic"/"non-atomic" altogether - now it is just
> "make no atomicity guarantee"
Not sure this is relevant, but isn't "opaque" access the way to request
atomicity "by all means possible"? So a user who cares can use `VH::getOpaque`
if the requirement is atomicity aligned to `CAS`.
I still agree that it is good to specify the meaning of plain `VH::get` and
`VH::set` as much as possible.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2214474938
