I still can't find anything "authoritative and unambiguous" on this. Therefore apps are going to be released with bugs in them. Can someone please say specifically when it is _not_ safe to use 64-bit atomic operations?
When it is unsafe on a 64-bit OS? When it is unsafe on a 32-bit OS? John On Sunday, February 5, 2017 at 4:34:05 AM UTC+13, Axel Wagner wrote: > > I find this an inappropriate answer. Yes, they need care, but it should at > least be possible to figure out how to use them from reading documentation > (carefully). I tend to agree, that neither the spec nor the documentation > of the atomic package is particularly helpful about these questions; at > least I fail to read them in a way that unambiguously answers them. > Without an authoritative and unambiguous description about what is > guaranteed it is impossible to implement this robustly and if the spec > isn't sufficiently unambiguous, it's natural to ask questions. Saying "you > are not supposed to use them, unless you know how to use them" is, in > context of all of this, just shutting people out. > > FWIW, I read the spec > <https://golang.org/ref/spec#Size_and_alignment_guarantees>, Dave > Cheney's blog post <https://dave.cheney.net/2015/10/09/padding-is-hard> > about padding, the therein referenced #599 <https://golang.org/issue/599> and > the atomic-documentation <https://godoc.org/sync/atomic#pkg-note-bug>, I > find the whole situation still somewhat confusing. To try to interpret all > of this and answer OPs question: > > 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"). > > This means, that the compiler needs to align S on 64 bits. Now, #599 tells > us, that on some archs s.B will *not* be 64 bit aligned. This is in > accordance with the spec though, as confusing as that seems; the spec says > only, how *a variable of the same type *as s.B must be aligned, not how > s.B itself must be aligned (this is, where the confusion stems from). So a > compiler might or might not insert padding. > > What all of this means, I believe, is > * The atomic-documentation (maybe?) tells you, that the first field in a > struct can be relied upon to be aligned. It says "the first word", though, > and from what I can tell, there is nothing preventing a compiler to insert > arbitrary padding at the beginning of a struct, technically speaking. > * Thus you can guarantee that s.B is 8-byte aligned, by switching the > fields around > * Thus, your question about the embedding of expvar.Float seems to be > "yes, it's safe", as the struct itself must be 64-bit aligned, even if > embedded, and the 64-bit field is the only one contained > * Your question about WaitGroup seems to be answerable by referring to the > fact, that *technically *the noCopy field could misalign the data. But I > tend to agree, that this reading would allow us to use a uint64, if we > switch noCopy and state. Dave Cheney's blog post about padding wouldn't > create technical problems here, because noCopy isn't the last field, thus > gets no storage allocated… > * Also, all of that reading seems to suggest that there really is no > reliable, guaranteed way, to have multiple fields with a guaranteed > alignment. So, if you need multiple variables to be accessed by atomics, > you are out of luck. > > Now, all of that being said, my reading could also be wrong. In any case, > in my opinion, the fact that there is considerable guesswork involved, > seems to suggest, that the spec is either ambiguous or insufficient to > actually allow safe usage of atomics. It would be nice, if it could be a > bit more explicit about what happens to fields. I understand, though, that > we don't want to restrict too much the flexibility of a compiler to insert > padding. But maybe a guarantee about the first field (not "word", what does > that even mean?) of a struct being aligned, even the first fields (plural), > if they all have the same alignment as the struct, would be clear enough > *and* compatible with what compilers are already doing. > > > On Sat, Feb 4, 2017 at 3:31 PM, Lars Seipel <lars....@gmail.com > <javascript:>> wrote: > >> On Sat, Feb 04, 2017 at 01:30:49AM -0800, T L wrote: >> > Get it. This is quite bug prone to write programs on 64bit OSes and the >> > programs are expected to run on 32bit OSes too. >> >> Well, there's a reason the sync/atomic package docs have this statement >> right at the top: >> >> > These functions require great care to be used correctly. Except for >> special, >> > low-level applications, synchronization is better done with channels or >> the >> > facilities of the sync package. >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
