<div dir="auto"><div>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.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 6, 2023, 6:19 PM David Alayachew <<a href="mailto:davidalayachew@gmail.com">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace" class="gmail_default">Hello Valhalla Dev Team,<br><br>The post I am referring to is this one.<br><br><a href="https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-March/002206.html" target="_blank" rel="noreferrer">https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-March/002206.html</a><br><br>Specifically, the quote I want to highlight is this one.<br><br>> Framed this way, the Valhalla performance story<br>> simplifies to:<br>> <br>>   - Give up identity, get flattening on the stack;<br>>   - Further give up explicit initialization, get<br>>         flattening for small objects on the heap;<br>>   - Further give up atomicity, get flattening for<br>>         larger objects on the heap.<br><br>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.<br><br>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.<br><br>But the post seems to say something different. It seems to say that atomicity can be given up, even when dealing with mutability.<br><br>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.<br><br>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?<br><br>Thank you for your time and help!<br>David Alayachew</div></div>
</blockquote></div></div></div>