On Saturday, February 4, 2017 at 2:18:44 PM UTC+8, Matt Harden wrote: > > https://play.golang.org/p/VWysBwbPCu > > The above program prints 64-bit aligned addresses on the playground, but > that's a 64 bit platform (with 32 bit pointers). On a 32 bit platform x.j > is not guaranteed to be 64-bit aligned. The same would be true if we > substituted a WaitGroup for int64 in that example. >
The go source shown in my last comment doesn't think so. > > On Fri, Feb 3, 2017 at 8:49 PM T L <tapi...@gmail.com <javascript:>> > wrote: > >> >> >> On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote: >>> >>> Never mind; I just realized that a WaitGroup is not necessarily at the >>> start of an allocation or global variable. >>> >> >> Not very get it. >> Do you mean WaitGroup will be embedded in other types? >> So we can't use the 64bit atomic functions for all exported types in >> libraries? >> >> >>> >>> On Fri, Feb 3, 2017 at 7:01 PM Matt Harden <matt....@gmail.com> wrote: >>> >> Doesn't the statement "32-bit compilers to not ensure [64 bit alignment >>>> at the start of an allocation]" contradict the sync/atomic statement "The >>>> first word in a global variable or in an allocated struct or slice can be >>>> relied upon to be 64-bit aligned."? >>>> >>>> On Fri, Feb 3, 2017 at 6:44 AM Ian Lance Taylor <ia...@golang.org> >>>> wrote: >>>> >>>>> On Fri, Feb 3, 2017 at 5:38 AM, T L <tapi...@gmail.com> wrote: >>>>> > Why does WaitGroup.state method check 64-bit alignment at run time? >>>>> > Why not make the state field as the first word of WaitGroup struct? >>>>> > >>>>> > // https://golang.org/src/sync/waitgroup.go?s=1857:1892#L20 >>>>> > >>>>> > type WaitGroup struct { >>>>> > >>>>> > noCopy noCopy >>>>> > >>>>> > // 64-bit value: high 32 bits are counter, low 32 bits are waiter >>>>> count. >>>>> > >>>>> > // 64-bit atomic operations require 64-bit alignment, but 32-bit >>>>> > >>>>> > // compilers do not ensure it. So we allocate 12 bytes and then use >>>>> > >>>>> > // the aligned 8 bytes in them as state. >>>>> >>>>> Doesn't this comment explain the problem? >>>>> >>>>> 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...@googlegroups.com. >>>> >>>> >>>>> 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...@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.
