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

[-]

An example may be a Vector of 3 integers representing a coordinate in a 3d
voxel game. In such a case, each of the 3 integers has independent min and
max bounds, so tear among the 3 values doesn't create invalid coordinates.
This value can thus give up atomicity; it's up to users to access such a
value in the correct program order (like with volatile, synchronization)
shall they share it across threads.

On Thu, Apr 6, 2023, 6:19 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Valhalla Dev Team,
>
> The post I am referring to is this one.
>
>
> https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-March/002206.html
>
> Specifically, the quote I want to highlight is this one.
>
> > Framed this way, the Valhalla performance story
> > simplifies to:
> >
> >   - Give up identity, get flattening on the stack;
> >   - Further give up explicit initialization, get
> >         flattening for small objects on the heap;
> >   - Further give up atomicity, get flattening for
> >         larger objects on the heap.
>
> I have a basic understanding of atomicity -- you can see/interact with the
> before and after, but not the in between. However, if I want to change an
> object out to use another one, I have to replace it incrementally since it
> is a larger object, as mentioned. As a result, if I don't have atomicity,
> then someone might be able to see the in between -- when part of the object
> is old data and some of the object is new data. Even if I zero out the data
> before doing so, that just widens my chance of running into the same
> problem, but for different combinations of data.
>
> Now, if the data we are working with is unchanging after initialization,
> then I see the value in this. Let's say I construct a List whose types are
> these non-atomic objects. Well, as long as all data contained within that
> List never changes, then I am still safe. And when I say never changes, I
> mean the List containing the objects, the components of each object, and
> even the components components, etc all the way down to the leaf nodes of
> each component of each object in the List, never change.
>
> But the post seems to say something different. It seems to say that
> atomicity can be given up, even when dealing with mutability.
>
> My question is, in what situation would we want to give up atomicity while
> still maintaining mutability? And that goes triple when dealing with larger
> objects.
>
> I want to use and test this feature myself, but I can't think of a
> situation where I would use it with mutability because I fear shooting
> myself in the foot when I accidentally read and write at the same time. How
> do I give up atomicity and keep mutability without shooting myself in the
> foot?
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230406/5896931d/attachment.htm>