On Saturday, February 4, 2017 at 2:51:53 PM UTC+8, Axel Wagner wrote: > > On Sat, Feb 4, 2017 at 5:49 AM, 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? >> > > You can, but must make sure that they are aligned properly. Either like > WaitGroup does, or, for example, by using the common idiom of factory > functions that do the allocation (or by just putting it on the user to make > sure). >
Get it. This is quite bug prone to write programs on 64bit OSes and the programs are expected to run on 32bit OSes too. > > >> >> >>> >>> 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.
