[foreign-memaccess] RFR: Fix concurrent MemoryScope.close() or MemoryScope.dup() race

[Maurizio Cimadamore]

On Mon, 11 May 2020 22:29:27 GMT, Peter Levart <plevart at openjdk.org> wrote:

> In case a MemorySegment is not confined to an "owner" thread, it is possible to call close() or
> withOwnerThread(newThread) on it from multiple threads concurrently and such calls are not screened for thread
> confinement but just forwarded to MemoryScope.close() and .dup(). It is therefore vital that close() and dup() are made
> atomic so that cleanupAction is executed just once.

I've been playing around a bit and discussed this offline with @JornVernee too. A realization I had some time ago is
that what we're trying to do here is a read/write lock, where multiple acquire can occur at the same time, but where
close of the root should be exclusive. I think all the machinery around CLOSING is essentially due to the code trying
to mimic that pattern.

I've put together this code:
https://gist.github.com/mcimadamore/54fecd888bcdc8fcf8aefaa51d4cbcbd

Which, I think, simplifies over the status quo, and also adds back the atomicity seeked in the proposed patch. Also,
since now there some guarantee that no acquire can take place while a close is also taking place (and pending acquires
will be invalidated - using the optimistic read logic), then we can just use a single long adder instead of two.

The state is also simplified, since we just need a boolean flag.

This seems to provide same numbers as what we have now, but IMHO the code is bit easier to follow, as there are less
moving parts. What do you think?

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/160