作者回复: 临界区其实就是一个代码片段。但这个代码片段中有共享的数据,这些数据不支持多个goroutine的并发访问,只能通过像channel、锁等机制同步各个goroutine的访问。同一时间,只能有一个goroutine访问这段代码,修改或读取这段代码所共享的数据。
作者回复: 👍
作者回复: 👍
作者回复: 👍
作者回复: 1. 可以的。 2. 虽然Broadcast的参考文档也提到了:It is allowed but not required for the caller to hold c.L during the call. 对于例子来说两种写法都是ok的。但条件变量的测试条件表达式,比如本例子中的ready最好是始终在lock的保护下的。所以这里我建议用了第一种。否则在复杂的场景下,一旦unlock,条件变量测试表达式 就不受控了。
作者回复: 没有。Go团队认为递归锁或可重入锁是一个bad idea,所以不支持。
作者回复: 多数情况下,对性能没有那么高要求,采用基于csp模型的并发设计是主流。
作者回复: Go中没有volatile。但go给出了自己的memory model,https://go.dev/ref/mem 这个也许能回答你的问题。
作者回复: 你的想法没错。但条件变量的性能我还真没有和channel对比过,介绍条件变量只是为了给大家“科普”一下它的存在和适合的场景。说实话,条件变量使用的很少。
作者回复: 你说的没错,无论整型变量和自定义类型变量,atomic的操作实质上针对的都是字长长度的指针。但我说的复杂临界区,还有另外一个情况,那就是在锁内部有着对数据的更为复杂的判断与操作,而不仅仅是+n,-n,或cas。