<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!<br>David Alayachew</div><br></div>