I understand. My point was you could induce tearing of a single field via that scenario and not just via a CPU that doesn't have low level load/store granularity that can impact neighbors due to too wide of a load/store. On Tue, Jan 17, 2017 at 7:15 PM Dave Cheney <d...@cheney.net> wrote:
> > Yeah, "word tearing" is an overloaded term. You can also consider > splitting a word across cachelines as potentially causing a tear as a > store/load involves two cachelines > > > > If a word was split across cache lines, it is by definition not > > aligned, so the guarantees of an atomic write don't apply, cache or no > > cache. > > > > On Wed, Jan 18, 2017 at 8:02 AM, Vitaly Davidovich <vita...@gmail.com> > wrote: > > > > > > > > > On Tue, Jan 17, 2017 at 3:39 PM, Aleksey Shipilev > > > <aleksey.shipi...@gmail.com> wrote: > > >> > > >> On 01/17/2017 12:55 PM, Vitaly Davidovich wrote: > > >> > Atomicity of values isn't something I'd assume happens automatically. > > >> > Word > > >> > tearing isn't observable from single threaded code. > > >> > > >> On 01/17/2017 09:17 PM, Michael Barker wrote: > > >> > That was my understanding too. Normal load/stores on 32 bit JVMs > would > > >> > tear 64 > > >> > bit values. Although, I think object references are guaranteed to be > > >> > written > > >> > atomically. > > >> > > >> (Triggered by my pet peeve) > > >> > > >> Please don't confuse "access atomicity" and "word tearing". Access > > >> atomicity > > >> means reading/writing the value in full. Word tearing (at least per JLS > > >> 17.6) > > >> means that fields are considered distinct, and the read/write of one > field > > >> cannot disturb neighbors. > > > > > > Yeah, "word tearing" is an overloaded term. You can also consider > splitting > > > a word across cachelines as potentially causing a tear as a store/load > > > involves two cachelines. But my point was really that word tearing and > > > access atomicity (or lack thereof) aren't observable in single threaded > > > code. > > >> > > >> > > >> Speaking of access atomicity, the upcoming value types would probably be > > >> non-access-atomic by default too, because enforcing access atomicity for > > >> widths > > >> larger than a machine one is painful. volatile longs/doubles had it easy > > >> on > > >> 32-bit VMs with 64-bit FPUs, compared to what variable-len values would > > >> have to > > >> experience. > > > > > > I don't see how they could be access atomic either. > > >> > > >> > > >> Thanks, > > >> -Aleksey > > >> > > >> > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "mechanical-sympathy" group. > > >> To unsubscribe from this group and stop receiving emails from it, send > an > > >> email to mechanical-sympathy+unsubscr...@googlegroups.com. > > >> For more options, visit https://groups.google.com/d/optout. > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "mechanical-sympathy" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to mechanical-sympathy+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to mechanical-sympathy+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
