06 | WaitGroup：协同等待，任务编排利器

老师好！接 linxs 同学的提问，我觉得他是一开始没表述清楚问题，我之前也有类似的疑问，后来仔细想了想我是这么理解这个问题的，也想请教老师看理解的 -------------------------------------------------- 为什么32bit系统的处理上，state1的元素排列和64bit的不同呢 64bit ： waiter,counter,sem 32bit ： sem,waiter,counter ------------------------------------------------------ 首先要理解的是**内存对齐**，32 位机和 64 位机的差别在于每次读取的块大小不同，前者一次读取 4 字节的块，后者一次读取 8 字节的块。 `WaitGroup` 的大小是 12 字节，接下来我声明了一个 `var wg sync.WaitGroup`，假设此处 wg 的内存地址是 0xc420016240，此时这个地址是 64bit 对齐的，因此这里的重点是**不论是 32 位机器还是 64 位机器，state1 的元素排列都是 `waiter,counter,sem`**。wg 的地址空间是 `0xc420016240~0xc42001624c`，因此如果此时是 64 位机的话还有4字节的空间可以分配给其他大小合适的变量。那此时 state1 的排列能不能是 `sem,waiter,counter` 呢？不能，因为 64 bit 值的原子操作必须 64 bit 对齐。 对于 32 位机器就会有一种**特殊情况**，那就是 wg 的内存地址起始被分配到了 0xc420016244，此时这个地址不是 64 bit 对齐的，因此这个时候排列变成了 `sem,waiter,counter`，这样的话，`waiter` 的起始地址变成了 0xc420016248，可以使用 64 bit 值的原子操作。

issue 12813 按照 defer 后进先出的原则，Done 一定会在 Add 之前执行吧，为啥是“可能”呢？

老师你好，我想问一下，为啥64位的int要保证原子操作就一定要64位对齐呢，那么为啥要这样规定呢？之前看到atomic文档后面说了一句就是就是说有部分32位处理器需要使用者自行对齐来保证atomic包中方法的正确性，是不是就是因为waitgroup用了atomic包的东西，为了保证atomic使用的正确才有这样的规定。 atomic文档的内容是：On ARM, x86-32, and 32-bit MIPS, it is the caller’s responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned.

没理解错的话，waiter 数量对应的应该是调用 Wait() 的 goroutine 的数量吧，文中的示例代码都只是在 main goroutine 中调用一次，所以 waiter 数量都只是 1 ，没错吧

32位/64位对齐的思考： 如果内存地址不是64位对齐，则让seman填充第一个32位，这样子就可以使得后面的state以64位对齐（因为state存储的两个值要同步修改）。

老师好，Add() 中，先将delta<<32位，加入counter，是不是counter应该在waiter位前，即 64bit ： counter,waiter,,sem 32bit ： sem,counter,waiter

老师好，我想问一下，为什么不在waitgroup中使用32位的原子操作？state1代表的三个值，其实都各占32bit，分离他们并且使用32位的原子操作，不是应该更好理解吗？

// 阻塞休眠等待 runtime_Semacquire(semap) -------------- 没理解『阻塞休眠等待』的意思，能否再详细讲一下。

如果你想要自己定义的数据结构不被复制使用，或者说，不能通过 vet 工具检查出复制使用的报警，就可以通过嵌入 noCopy 这个数据类型来实现。 这里不应该是能通过vet工具检查出复制吗。。看起来怪怪的。

为什么32bit系统的处理上，state1的元素排列和64bit的不同呢 64bit ： waiter,counter,sem 32bit ： sem,waiter,counter