diff --git a/thu_os/chp11.md b/thu_os/chp11.md
index 93384c2..b7a45a9 100644
--- a/thu_os/chp11.md
+++ b/thu_os/chp11.md
@@ -111,13 +111,13 @@
 
 这里我们主要考虑的指标是音频文件播放是否流畅、连贯。为此，就需要设计的应用程序可以及时将刚读出来的压缩数据解压缩，并且播放出来。一种简明的设计思路如下图所示：
 
-![mp3_version_1](images/map_version1.png)
+![mp3_version_1](images/mp3_version1.png)
 
 在该设计思路中，我们将读取数据，解压缩，播放文件依次执行。但是不难看出，这种实现存在很致命的缺陷：各个模块之间不能并行进行。可以看到，这里读取压缩音频文件涉及到I/O操作，解压缩是CPU密集型操作，因此这两个模块在理论上是可以并发执行的，即在将压缩文件读取出来的同时，CPU可以对这些数据进行解压缩，这样可以大幅度提高资源的利用效率。此外，按照我们的设想，在播放时应该也可以同时进行读文件和解压的操作，在这种实现方式都却不能做到。在这种实现下，为了播放音频文件连贯，必须一次性将全部音频文件读出并且解压缩，最后才能播放，漫长的等待时间非常影响用户体验。
 
 为了将各个操作并行地推进，我们很自然地联想到将各个核心模块全都加载到一个进程中，即为了运行这个MP3播放器软件，我们同时需要三个进程，这种设计思路如下图所示：
 
-![mp3_version_2](images/map_version2.png)
+![mp3_version_2](images/mp3_version2.png)
 
 这种方法的确解决并行的问题，但是却引入了新的问题——可以看到，这里的三个进程之间需要共享数据，前一个进程的输出，是下一个进程的输入，因此需要解决在进程之间通信以及共享数据的问题。此外，进程的创建以及进程之间的切换是需要相当的开销的，这种实现方式无疑增加了开销。
 
diff --git a/thu_os/images/kern_thread.png b/thu_os/images/kern_thread.png
new file mode 100644
index 0000000..407a54c
Binary files /dev/null and b/thu_os/images/kern_thread.png differ