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

[David Alayachew]

Ok, perfect. This puts all of my concerns to rest. Thank you so much!

On Mon, Apr 10, 2023 at 6:34 AM Quân Anh Mai <anhmdq at gmail.com> wrote:

> 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.
>
> On Mon, 10 Apr 2023 at 18:11, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> 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/981f4208/attachment.htm>