On Wed, 16 Jul 2025 09:28:28 GMT, Raffaello Giulietti <rgiulie...@openjdk.org>
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> "may be non-atomic"
>
> 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"
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2213964762
