<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Ok, perfect. This puts all of my concerns to rest. Thank you so much!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 10, 2023 at 6:34 AM Quân Anh Mai <<a href="mailto:anhmdq@gmail.com">anhmdq@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Yes, the usage of synchronisation mechanisms is not likely to affect the layout of the non-atomic object in local variables and in the heap.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Apr 2023 at 18:11, David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace" class="gmail_default">Hello Quan Anh,<br><br>Thank you for your response!<br><br>> Hi,<br>> <br>> Atomicity is the behaviours of memory reads/writes under<br>> race conditions. If there is no race condition (the<br>> variable is not accessed from multiple threads or<br>> protected properly by locks) then the observed value is<br>> always the latest written one. As a result, if you<br>> serialise your accesses properly, there is no need to<br>> worry about atomicity. And in general, it should be rare<br>> that you want to access variables without proper<br>> synchronisations, and you should not do so.<br><br>Beautiful. That spelled it out perfectly for me.<br><br>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.<br><br>> As this is rather uncommon and requires you doing clever<br>> things for it to make differences. Other languages often<br>> do not worry giving up this property. C and C++ straight<br>> invalidate your entire program, Go and C# give you<br>> unspecified result when accessing variables larger than<br>> machine word.<br>> <br>> In conclusion, you will most likely not observe the<br>> non-atomicity of any variable, except when you are trying<br>> to do clever things (accessing variables racily) and in<br>> those cases, you need to carefully study the Java memory<br>> model.<br>> <br>> To quote from the Go memory model: Don't be clever.<br><br>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.<br><br>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.<br><br>Thank you for the insight and clarification!</div></div><div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br>David Alayachew</div><br></div>
</blockquote></div></div>
</blockquote></div>