add the image

Skycrab · Mar 1, 2013 · 6f7c915 · 6f7c915
1 parent 62d387a
commit 6f7c915
Show file tree

Hide file tree

Showing 3 changed files with 2 additions and 2 deletions.
diff --git a/all.org b/all.org
@@ -347,7 +347,7 @@ runtime.exitsyscall函数中,如果退出系统调用后mcpu小于mcpumax,直接
 现在Gwaiting,Grunnable,Grunning,Gwaiting都出现过的,接下来看最后两种状态Gmoribund和Gdead.看runtime.goexit函数.这个函数直接把g的状态设置成Gmoribund,然后调用gosched,进入到schedule中.在schedule中如果遇到状态为Gmoribund的g,直接设置g的状态为Gdead,将g与m分离,把g放回到free队列.
 --------
 接下来看一些有意思点的吧,先不读代码了.一个常规的 线程池+任务队列 的模型如图所示:
-./image/worker.jpg
+[[file:image/worker.jpg]]
 把每个工作线程叫worker的话,每条线程运行一个worker,每个worker做的事情就是不停地从队列中取出任务并执行:
 #+begin_src c
 while(!empty(queue)) {
@@ -372,7 +372,7 @@ struct G {
 一个线程是一个worker,假如运行到阻塞了呢?那干事的家伙岂不就少了,解耦还是不够.所以不是一个worker对应一条线程的,go语言中又引入了struct M这层抽象.m就是这里的worker,但不是线程.处理系统调用中的m不会占用线程,只有干事的m才会对应线程.
 
 于是就变成了这样子:
-../image/m_g.jpg
+[[file:image/m_g.jpg]]
 然后就变成了线程的入口是mstart,而goroutine的入口是在schedule中m和g都满足之后切换上下文进入的.
 只是由于要优化,所以会搞的更复杂一些.比如要重用内存空间所以会有gfree和mhead之类的东西.
 * 收集的一些关于go internals的链接：

diff --git a/image/m_g.jpg b/image/m_g.jpg
diff --git a/image/worker.jpg b/image/worker.jpg