Question about multi threads visiting shared arena

[Maurizio Cimadamore]

Hi,
accessing a shared memory segment is pretty much the same as accessing a 
byte buffer, or a Java array instance. There are no additional memory 
fences that are added by our implementation when using "plain" access 
(as in all the other APIs I have listed), so, in the general case you 
would probably need to use VarHandle::fullFence() or something similar 
(to make sure all writes are flushed when one thread is done with the 
segment).

It is surprising to see that it worked even w/o adding 
synchronization/fencing, but that might just be "luck", or the 
particular system you are using, as is often the case with these 
matters. From a low-level/implementation perspective there is absolutely 
no happens-before relationship inserted between writes on a memory 
segment and reads on the same segment (when using VarHandle::get - that 
is - a "plain" read/write). That is, plain access really means plain access.

Hope this helps.

Maurizio

On 27/03/2023 08:48, 刘希晨 wrote:
> I have a question about using MemorySegment with Arena.openShared().
> I don't know if the memory created by Arena.openShared() or any other 
> shared scope would be safely accessed by multiple threads.
> Simply put, if a writer thread wrote something into the MemorySegment 
> and then passing it to the reader thread using a BlockingQueue,
> I am confused if the writer operation would already be visible to the 
> reader thread.
> I have tested its visibility using jcstress and it turns out every 
> Varhandle.get() will successfully read the data changed in another 
> thread,
> even without volatile or locks, so I am confused if the jvm has 
> already created memory fence for memorysegment's access.
> I hope the authorities could offer a suggested way of accessing same 
> memory segment in multiple threads in Panama FFI's documentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230327/606c4268/attachment.htm>