holdtom

这里有几点值得注意：goroutines 不是线程。没有“goroutine 数量”，系统中的 goroutine 数量也没有固定的上限。1&nbsp;可以修改 Bakery 算法以处理动态创建的线程（使用列表或映射，如 Wikipedia 页面上的 Java 示例），但对每个“线程”有一个唯一 ID 的强烈要求，这使得这不是一个一般而言，Go 的好主意。（您可以依次使用实现类似线程行为的包来解决这个问题，包括线程 ID。）正如维基百科页面所指出的：Lamport 的面包店算法假设一个顺序一致性内存模型。很少有（如果有的话）语言或多核处理器实现这样的内存模型。因此，算法的正确实现通常需要插入栅栏来禁止重新排序。这意味着您将需要使用该sync/atomic包，这违背了编写自己的锁定的目的。有了这两个巨大的警告，你可以调用runtime.Gosched()你会调用 POSIX 样式yield()函数的地方，或者你可以使用一个通道来表示有人“离开了面包店”，因此轮到下一个用户了。但是渠道本身会完成您需要的所有互斥。一个简化的特定于 Go 的非 Lamport 面包店算法是微不足道的（但以下所有内容都未经测试）：var takeANumber chan int64var currentlyServing int64init() {&nbsp; &nbsp; takeANumber = make(chan int64)&nbsp; &nbsp; go giveNumbers()}// giveNumbers hands out ever-increasing ticket numbersfunc giveNumbers() {&nbsp; &nbsp; for int64 i := 0;; i++ {&nbsp; &nbsp; &nbsp; &nbsp; takeANumber <- i&nbsp; &nbsp; }}// WaitTurn gets a ticket, then waits until it is our turn.&nbsp; You can// call this "Lock" if you like.func WaitTurn() int64 {&nbsp; &nbsp; ticket := <-takeANumber&nbsp; &nbsp; for atomic.LoadInt64(&currentlyServing) < ticket {&nbsp; &nbsp; &nbsp; &nbsp; runtime.Gosched()&nbsp; &nbsp; }&nbsp; &nbsp; return ticket}// ExitBakery relinquishes our ticket, allowing the next user to proceed.func ExitBakery(ticket int64) {&nbsp; &nbsp; atomic.StoreInt64(&currentlyServing, ticket + 1)}将其修改为使用两个通道，以便该WaitTurn功能更有效，留作练习。（当然，除了作为练习之外，没有理由一开始就使用这些代码。）1您可以设置运行时限制，但如果您调用任何阻塞系统调用，系统无论如何都会产生额外的 goroutine。阻塞的系统调用集以及何时调用它们取决于运行时，因此您无法对此进行真正的控制，至少在不编写特定于平台的代码的情况下是无法控制的。
0 0