Merge pull request RT-Thread#43 from aozima/pulls

fix spell errors, fixed RT-Thread#40.

Author: BernardXiong

zh/1chapters/04-chapter_ipc.md

@@ -448,7 +448,7 @@ RT_EOK
         }
         else
         {
-            /* 因为没有其他地方是否信号量，所以不应该成功持有信号量，否则测试失败 */
+            /* 因为没有其他地方释放信号量，所以不应该成功持有信号量，否则测试失败 */
             tc_done(TC_STAT_FAILED);
             rt_sem_detach(&sem);
             return;
@@ -660,7 +660,7 @@ static rt_thread_t consumer_tid = RT_NULL;
 struct rt_semaphore sem_lock;
 struct rt_semaphore sem_empty, sem_full;
 
-/* 生成者线程入口 */
+/* 生产者线程入口 */
 void producer_thread_entry(void* parameter)
 {
     rt_int32_t cnt = 0;
@@ -813,7 +813,7 @@ int rt_application_init()
 
 #### 锁 ####
 
-锁，单一的锁常应用于多个线程间对同一临界区的访问。信号量在作为锁来使用时，通常应将信号量资源实例初始化成1，代表系统默认有一个资源可用。当线程需要访问临界资源时，它需要先获得这个锁资源。当这个线程成功获得资源锁时，其他打算访问临界区的线程将被挂起在该信号量上，这是因为其他线程在试图获取这个锁时，这个锁已经被锁上（信号量值是0）。当获得信号量的线程处理完毕，退出临界区时，它将会释放信号量并把锁解开，而挂起在锁上的第一个等待线程将被唤醒从而获得临界区的访问权。
+锁，单一的锁常应用于多个线程间对同一临界区的访问。信号量在作为锁来使用时，通常应将信号量资源实例初始化成1，代表系统默认有一个资源可用。当线程需要访问临界资源时，它需要先获得这个资源锁。当这个线程成功获得资源锁时，其他打算访问临界区的线程将被挂起在该信号量上，这是因为其他线程在试图获取这个锁时，这个锁已经被锁上（信号量值是0）。当获得信号量的线程处理完毕，退出临界区时，它将会释放信号量并把锁解开，而挂起在锁上的第一个等待线程将被唤醒从而获得临界区的访问权。
 
 因为信号量的值始终在1和0之间变动，所以这类锁也叫做二值信号量，如图 ***锁*** 所示：
 
@@ -840,11 +840,11 @@ semaphore先初始为0，而后shell线程试图取得信号量，因为信号
 
 ## 互斥量 ##
 
-互斥量又叫相互排斥的信号量，是一种特殊的二值性信号量。它和信号量不同的是，它支持互斥量所有权、递归访问以及防止优先级翻转的特性。互斥量工作示意图如图 ***互斥量的工作示意图*** 所示。
+互斥量又叫相互排斥的信号量，是一种特殊的二值性信号量。它和信号量不同的是，它支持互斥量所有权、递归访问以及防止优先级翻转的特性。互斥量工作如 ***互斥量的工作示意图*** 所示。
 
 ![互斥量的工作示意图](figures/rt_mutex_semaphore.png)
 
-互斥量的状态只有两种，开锁或闭锁（两种状态值）。当有线程持有它时，互斥量处于闭锁状态，由这个线程获得它的所有权。相反，当这个线程释放它时，将对互斥量进行开锁，失去它的所有权。当一个线程持有互斥量时，其他线程将不能够对它进行开锁或持有它，持有该互斥量的线程也能够再次获得这个锁而不被挂起。这个特性与一般的二值信号量有很大的不同，在信号量中因为已经不存在实例，线程递归持有会发生主动挂起（最终形成死锁）。
+互斥量的状态只有两种，开锁或闭锁（两种状态值）。当有线程持有它时，互斥量处于闭锁状态，由这个线程获得它的所有权。相反，当这个线程释放它时，将对互斥量进行开锁，失去它的所有权。当一个线程持有互斥量时，其他线程将不能够对它进行开锁或持有它，持有该互斥量的线程也能够再次获得这个锁而不被挂起。这个特性与一般的二值信号量有很大的不同，在信号量中，因为已经不存在实例，线程递归持有会发生主动挂起（最终形成死锁）。
 
 使用信号量会导致的另一个潜在问题是线程优先级翻转。所谓优先级翻转问题即当一个高优先级线程试图通过信号量机制访问共享资源时，如果该信号量已被一低优先级线程持有，而这个低优先级线程在运行过程中可能又被其它一些中等优先级的线程抢占，因此造成高优先级线程被许多具有较低优先级的线程阻塞，实时性难以得到保证。例如：有优先级为A、B和C的三个线程，优先级A> B > C。线程A，B处于挂起状态，等待某一事件触发，线程C正在运行，此时线程C开始使用某一共享资源M。在使用过程中，线程A等待的事件到来，线程A转为就绪态，因为它比线程C优先级高，所以立即执行。但是当线程A要使用共享资源M时，由于其正在被线程C使用，因此线程A被挂起切换到线程C运行。如果此时线程B等待的事件到来，则线程B转为就绪态。由于线程B的优先级比线程C高，因此线程B开始运行，直到其运行完毕，线程C才开始运行。只有当线程C释放共享资源M后，线程A才得以执行。在这种情况下，优先级发生了翻转，线程B先于线程A运行。这样便不能保证高优先级线程的响应时间。
 
@@ -1808,7 +1808,7 @@ rt_mb_send_wait与rt_mb_send的区别在于，如果邮箱已经满了，那么
  * 程序清单：邮箱例程
  *
  * 这个程序会创建2个动态线程，一个静态的邮箱对象，其中一个线程往邮箱中发送邮件，
- * 一个线程往邮箱中收取邮件。
+ * 一个线程从邮箱中收取邮件。
  */
 #include <rtthread.h>
 #include "tc_comm.h"
@@ -2443,7 +2443,7 @@ void message_handler()
 
 #### 同步消息 ####
 
-在一般的系统设计中会经常遇到要发送同步消息的问题，这个时候就可以根据当时的状态选择相应的实现：两个线程间可以采用一个[消息队列+ 信号量]或邮箱的形式实现。
+在一般的系统设计中会经常遇到要发送同步消息的问题，这个时候就可以根据当时的状态选择相应的实现：两个线程间可以采用**[消息队列+信号量]**或邮箱的形式实现。
 发送线程通过消息发送的形式发送相应的消息给消息队列，发送完毕后希望获得接收线程的收到确认，工作示意图如图 ***同步消息发送*** 所示：
 
 ![同步消息发送](figures/rt_synchronous_message.png)

zh/1chapters/08-chapter_application.md

@@ -8,7 +8,7 @@
 
 当前RT-Thread支持应用模块的架构包括arm7、arm9、cortex M0/M3/M4。当前RT-Thread内核可使用多种编译器，如GCC, ARMCC、IAR等工具链，模块编译只支持GCC工具链，因此编译RT-Threas模块需下载GCC工具，笔者使用的是CodeSourcery的arm-none-eabi工具链。
 
-应用模块也带来了一定的限制，它仅支持加载到RAM中运行，而不能直接在flash上运行，向此RAM耗费会到一些。
+应用模块也带来了一定的限制，它仅支持加载到RAM中运行，而不能直接在flash上运行，因此，RAM耗费的会多一些。
 
 ## 使用应用模块 ##