[foreign-jextract] RFR: Minor change for possible race in shared resource list [v2]

[Maurizio Cimadamore]

On Sat, 24 Apr 2021 16:14:05 GMT, Radoslaw Smogura <github.com+7535718+rsmogura at openjdk.org> wrote:

>> (1) One or more threads can see "prev" as CLOSED_LIST. Even those CAS will be performed
>> and list head will be set to new cleanup. Than exception is going to be thrown.
>> 
>> (2) Than cleanup will continue (maybe skipping just added cleanup).
>> 
>> If in addition, other thread will join in parallel to (1) with cleanup2, than
>> queue could look like this HEAD = cleanup2 -> list end marker.
>
> Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make update of list head (FST) using atomic CAS, because
>   `cleanup` method can race with `add` about changing FST.
>   
>   Small code re-arrangement, to disable double load of FST during first loop pass

I'm starting to get a bit skeptical of this code. In general we try to be lock free where possible, which is fine. We certainly need to be lock free for things like memory access, as the cost of locking is way larger than that associated with memory access.

We also need a lock-free acquire scheme, as accessor threads might want to do acquire/access/release (actually, in this case contention is also an important factor and I'm not sure CAS will deliver best results, but, fine for now, we can uber optimize later).

In the case of close vs. add I'm less sure that the performance component is critical. One thread wants to shut the resource scope down for good. The other is attempting to perform some kind of setup operation on the scope. It seems to me that these two operation (close/add) generally belong to different "stages" of a resource scope life cycle.

So, while it is possible to come up (with some complication) with a lock free scheme which allows adds and close to occur safely between threads, I'm less sure here that the extra complication justifies the cost.

Since I don't think we care of being able to "race" between close/add, I think the question boils down to: how much do we care that two different threads are not able to add a cleanup action _on the same scope_ without a lock?

In other words, let's suppose, for a moment, that shared ResourceScope had its "add" and "close" method synchronized (either using the `synchronized` keyword, or with other means). Would that result in a loss of usability or performance for clients? In other words, can we make resource list always based on a single-thread assumption?

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

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