MemorySegment - request ownership - release ownership - ownership strategy

[Maurizio Cimadamore]

Hi,
My sense is that here we are leaving the scope of a low level API 
targeting memory access and we're deep into data-structure design territory.

Wouldn't these use case be better solved by having a separate ownership 
blocking queue which adheres to some policy, rather than turning the 
memory segment itself into a queue?

Segment ownership is mostly a means to achieve a goal (e.g. fast access, 
cheap release), and not a goal per se (e.g. it is beyond the scope of 
this API to provide a fully complete ownership system).

At the moment there are at least three ways in which clients can 
interact with segments:

1) confined: thread owner stays the same (or is rarely tweaked via 
handoff operations), access and close are fast
2) shared: there's no owner, access is still fast, close operation pays 
a price to ensure correctness
3) shared + cleaner, implicit deallocation (like ByteBuffers) - access 
is still fast, latency of a close operation is non-deterministic

Each mode has its own use cases; (1) might be more useful e.g. in the 
context of a native function call; (2) might be useful when mapping 
large files into memory (where you don't care much about performances of 
close() - but you DO care a lot that memory will eventually be unmapped) 
- (3) is useful in cases where non-deterministic behavior is acceptable 
- e.g. if a segment is meant to be long-lived (e.g. its lifecycle is as 
long as that of the application).

While we can make the ownership system more complex at will (this is a 
big space!) - I think that there should be a clear use case as to why 
any idiom that doesn't fit in (1), (2) or (3) must belong to the API 
(rather than coded outside of it): the richer we make the ownership 
mechanism, the harder will be for _all_ users to understand how 
MemorySegments are and what they are for.

Cheers
Maurizio

On 12/12/2020 16:59, Suminda Sirinath Salpitikorala Dharmasena wrote:
> Hello,
>
> An API which can be added to MemorySegment is to:
> - request ownership and
> - release ownership (internally may set withOwnerThread(null))
>
> A thread requesting ownership will block until the ownership assigned to
> the calling thread. Requests will be served according to a strategy which
> can be:
> - FIFO
> - Random
> - Prioritised by threads which had the least ownership of the segment
> - etc.
>
> This way the transfer of ownership would be systematic.
>
> Also the MemorySegment and ownerships strategy can determine the next owner
> if the ownership is released without setting an owner explicitly and there
> are no requests for ownership pending.
>
> So the new APIs would be:
> - releaseOwnership()
> - requestOwnership()
> - setOwnershipStratergy(strategy)
>
> Suminda