Trying to understand atomicity from the new valhalla-spec-observers post

[David Alayachew]

Hello Quan Anh,

Thank you for your response!

> Hi,
>
> Atomicity is the behaviours of memory reads/writes under
> race conditions. If there is no race condition (the
> variable is not accessed from multiple threads or
> protected properly by locks) then the observed value is
> always the latest written one. As a result, if you
> serialise your accesses properly, there is no need to
> worry about atomicity. And in general, it should be rare
> that you want to access variables without proper
> synchronisations, and you should not do so.

Beautiful. That spelled it out perfectly for me.

Something like object tearing sounds scary and unpredictable, but knowing
that it can ONLY occur when dealing with multiple threads accessing the
same field makes me much more comfortable. That means that this is nothing
more than a race condition with a much bigger punishment if you get it
wrong. Beautiful, ty vm.

> As this is rather uncommon and requires you doing clever
> things for it to make differences. Other languages often
> do not worry giving up this property. C and C++ straight
> invalidate your entire program, Go and C# give you
> unspecified result when accessing variables larger than
> machine word.
>
> In conclusion, you will most likely not observe the
> non-atomicity of any variable, except when you are trying
> to do clever things (accessing variables racily) and in
> those cases, you need to carefully study the Java memory
> model.
>
> To quote from the Go memory model: Don't be clever.

I can definitely see what you mean. At this point, I have no desire at all
to ever let any of my tearable objects ever leave the boundaries of my
synchronization tools.

Let me ask this though. If I apply synchronization or some other concurrent
access tool to my tearable object, do I still get to keep all of the large
object inlining that I made it tearable for in the first place? If so, then
that leads me to want to dive into the concurrency model so that I can
safely get the performance I want.

Thank you for the insight and clarification!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230410/b2cce0f0/attachment.htm>