On Fri, 26 May 2023 08:36:46 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/UUID.java line 224:
>>
>>> 222: // Try to pull the UUID from the current buffer at
>>> current position.
>>> 223: if (stamp != 0) {
>>> 224: int p = (int)VH_POS.getAndAdd(this,
>>> UUID_CHUNK);
>>
>> An atomic update together with an optimistic lock looks non-idiomatic use of
>> StampedLock to me. Won't a simple CAS loop be simpler? E.g. in pseudocode:
>>
>> while ((p = this.pos) + 16) < buf.length) {
>> long msb = getLong(buf, p);
>> long lsb = getLong(buf, p + 8);
>> if (cas(this.pos, p, p + 16)) {
>> return new UUID(msb, lsb);
>> }
>> }
>>
>> // refill buffer under lock
>
> Nope, I don't think you cannot do this, because there is a race on
> concurrently-updating `buf`. The StampedLock (RW lock), protects the
> buffer-reading threads from seeing the `buf` undergoing the initialization by
> buffer-writing threads. Atomic pos only arbitrates the concurrent
> buffer-threads. That atomic does not help to resolve the buf races.
Right, my example suffers from the ABA problem. It could be likely solved by
adding "generation" bits to the pos, but this will be a bit ugly. OK, let's
stick with the StampedLock.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206686499
