On Sat, Feb 4, 2017 at 7:33 AM, Axel Wagner
<axel.wagner...@googlemail.com> wrote:
>
> I believe, that fields do not necessarily need to be properly aligned
> (explaining 599). However, *structs* have a necessary alignment, as required
> by their fields. So, if you do
> type S struct {
> A uint32
> B uint64
> }
> then there is no guarantee, that B is 64-bit aligned. The spec tells us,
> that unsafe.Alignof(s.A) will return 4 ("The functions Alignof and Sizeof
> take an expression x of any type and return the alignment or size,
> respectively, of a hypothetical variable v as if v was declared via var v =
> x", s.A is of type uint32 and such a variable has alignment 4),
> unsafe.Alignof(s.B) will return 8 and thus, unsafe.Alignof(s) will return 8
> ("For a variable x of struct type: unsafe.Alignof(x) is the largest of all
> the values unsafe.Alignof(x.f) for each field f of x, but at least 1").
The spec does not say that unsafe.Alignof(s.B) will return 8. In
fact, on 32-bit targets, with the gc toolchain, it will return 4.
I think the spec and docs do provide enough information to use
sync/atomic correctly. "The first word in a global variable or in an
allocated struct or slice can be relied upon to be 64-bit aligned."
That is sufficient to ensure that your code works correctly. It does
mean that certain kinds of operations don't work. sync.WaitGroup
plays the games it does to avoid introducing an extra allocation.
There is probably something to be fixed here, to permit higher
efficiency without requiring trickiness like that of sync.WaitGroup,
but I'm not sure how it should be implemented.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
