On 01/20/2017 05:41 AM, Michael Matz wrote:
Hi,
On Wed, 18 Jan 2017, Richard Henderson wrote:
Section 3 Rationale, alternative 1: I'm wondering if the example is
correct. For a 4-byte-aligned type of size 3, the implementation
cannot simply use 4-byte hardware-backed atomics because this will
inevitably touch the 4th byte I think, and the implementation can't
know whether this is padding or not. Or do we expect that things like
packed structs are disallowed?
If we atomically store an unchanged value into the 4th byte, can we
tell?
You can't have a 4-aligned type of size 3. Sizes must be multiples of
alignment (otherwise arrays don't work). The type of a 3-sized field in
a packed struct that syntactically might be a 4-aligned type (e.g. by
using attributes on char-array types) is actually a different type having
an alignment of 1. It's easier to simply regard all types inside packed
structs as 1-aligned (which is IMO what we try to do).
That is, the byte after a 4-aligned "3-sized" type is always padding.
[ I read Bin Fan's original email some months ago, but I don't have it handy
now. Take faulty memory with a grain of salt. ]
I thought this was about libatomic being presented with an unaligned 3-byte
structure that happens to sit within an aligned 4-byte word, and choosing to
atomically operate on the 4-byte word instead of taking a lock on the side.
r~
