#《Concurrency in Go》

第 2 章、第 3 章的一些笔记

#第二章 Modeling Your Code: Communicating Sequential Processes

CSP:Communicating Sequential Processes

input and output are two overlooked primitives of programming.

参考链接:CSP(communicating sequential processes)并发模型

goroutines are lightweight, and we normally won’t have to worry about creating one.

Go’s runtime multiplexes goroutines onto OS threads automatically and manages their scheduling for us. This means that optimizations to the runtime can be made without us having to change how we’ve modeled our problem.

相当于一个黑盒子,不用去考虑下面的实现,下面的优化自然也不会影响程序的运行。

决定树

Package sync provides basic synchronization primitives such as mutual exclusion locks. Other than the Once and WaitGroup types, most are intended for use by low- level library routines. Higher-level synchronization is better done via channels and communication.

consider struc‐ turing your program so that only one goroutine at a time is ever responsible for a par‐ ticular piece of data.

Do not communicate by sharing memory. Instead, share memory by communicating.

我在stackoverflow上也问了这个问题,如何理解这张图。

其实我认为这个图应该像她在文章里讲得那样画,首先先判断是否需要转交数据的所有权,是的话其实就可以保证同一时间只有一个 goroutine 使用该数据,然后后面的一些判断。

这样做的好处是:

you’ve implicitly made your concurrent code composable with other concurrent code.

最后,当性能成为一个很重要的需要解决的问题的时候,才会抛弃 channels 而使用 primitives。

Try to keep the locks constrained to a small lexical scope.

为什么性能成为瓶颈的时候用原生的:

This is because channels use memory access synchronization to operate, therefore they can only be slower.

Go 的哲学:

Aim for simplicity, use channels when possible, and treat goroutines like a free resource.

#第三章 Go’s Concurrency Building Blocks

Green threads 也被翻译成绿色线程,它的相关资料:

Coroutines are simply concurrent subroutines (functions, closures, or methods in Go) that are nonpreemptive—that is, they cannot be interrupted. Instead, coroutines have multiple points throughout which allow for suspension or reentry.

Go’s runtime observes the runtime behavior of goroutines and automatically suspends them when they block and then resumes them when they become unblocked.

the goroutines being scheduled may run at any point in time in the future, it is undetermined what values will be printed from within the goroutine.

The Go runtime is observant enough to know that a reference to the salutation variable is still being held, and therefore will transfer the memory to the heap so that the goroutines can continue to access it.

golang 的运行时会足够聪明地知道还有什么变量还需要使用,不会被回收。

the garbage collector does nothing to collect goroutines that have been abandoned somehow. If I write the following:

1
2
3
4
go func() {
// <operation that will block forever>
}()
// Do work

如果 goroutine 里的代码永远运行着,那它就不会被垃圾回收。

Context switching in software is comparatively much, much cheaper.

在软件里的上下文切换,要比系统层面的轻量多了。

the more goroutines you create, and if your problem space is not constrained by one concurrent segment per Amdahl’s law, the more your program will scale with multiple processors.

看起来自己的笔记只有自己能懂。。

不过少数的问题可以给到别人启发也够了 :)