Thread safety check of MemorySegment

[Maurizio Cimadamore]

On 22/07/2020 11:26, Johannes Lichtenberger wrote:
> I'm also using a mapped memory segment. But I think at least we have 
> the possibility to transfer ownership in Java 15, right? Thus, in my 
> AutoClosable in the close() method I can simply transfer ownership to 
> the current thread if the segment is still alive :-)

Transfer of ownership must be initiated by the thread that owns the 
segment. If that works for you, then, yes, it can be used as a solution.

I was chatting with Jorn earlier, and he was thinking of something that 
I tried to implement at some point, but then I gave up; basically, the 
big issues with withOwnerThread is that (1) must be called by owner 
thread and (2) the owner thread must know the thread picking it up.

It is in principle possible to break up withOwnerThread in two halves: 
e.g. detach (removes ownership) +  attach (re-adds ownership to a 
detached segment).

So, if in your use cases, the workflow is clear enough that you know 
_when_ the segment is no longer being worked on, the owner thread could 
simply call something like MemorySegment::detach (and maybe put the 
segment on a queue); later on, another thread (a cleaner one?) might 
pick it up, attach to it, and call close.

Is this something that would help in the use cases being considered in 
this thread? Or does it still fall in the "too restrictive" category? My 
sense when speaking with Uwe at the committer workshop in January was 
that, at least for Lucene, this fell in the latter bucket (e.g. not enough).

Maurizio

>
> Kind regards
> Johanmes
>
> Maurizio Cimadamore <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> schrieb am Mi., 22. Juli 
> 2020, 11:51:
>
>
>     On 22/07/2020 00:44, Johannes Lichtenberger wrote:
>>     So, it likely will not be part of Java 15, right?
>     Right.
>>
>>     I'm running into the same problem, when I'm sharing a transaction
>>     (only one thread ever accesses it) with another thread and the
>>     other thread closes the transaction. Same problem with the
>>     segment close()-method.
>
>     Are you too also using mapped segments? Or just plain native
>     segments allocated with MemorySegment::allocateNative?
>
>     Thanks
>     Maurizio
>
>>
>>     kind regards
>>     Johannes
>>
>>     Am Mi., 22. Juli 2020 um 01:24 Uhr schrieb Maurizio Cimadamore
>>     <maurizio.cimadamore at oracle.com
>>     <mailto:maurizio.cimadamore at oracle.com>>:
>>
>>
>>         On 21/07/2020 22:51, NekoCaffeine wrote:
>>         >>
>>         https://gist.github.com/mcimadamore/128ee904157bb6c729a10596e69edffd
>>         > This is a great example.
>>         >
>>         >> The *right* solution from an API perspective is to find a
>>         way to disable confinement in a way that works
>>         > I very much agree with this point, which is exactly what I
>>         want to express.
>>         >
>>         > So from a design rather than implementation perspective,
>>         should I expect a new way to disable thread checking or
>>         should I use CustomMappedSegment?
>>
>>         So the crux of the issue here is that there's no Runnable
>>         that will
>>         unmap a given mapped address. But such a Runnable can be
>>         implemented in
>>         several ways:
>>
>>         * with plain JNI
>>         * using the ForeignLinker API (although that is not part of
>>         JDK 15 - but
>>         is available in the Panama repo)
>>         * going all in and re-implement mapped segment (similar to
>>         what I've
>>         done with CustomMappedSegment)
>>
>>         I think from an API perspective, if we manage to solve the
>>         confinement
>>         problem, then I expect the memory segment API will have an
>>         extra method
>>         to either turn a confined segment into an unconfined one, or
>>         vice-versa.
>>         So you will be able to just create your mapped segment using
>>         mapFromPath
>>         and then just 'share' it (and make it unconfined).
>>
>>         Hope this helps.
>>
>>         Maurizio
>>
>>         >
>>         > Thanks,
>>         >
>>         > NekoCaffeine
>>