大家好，到月底了，流光又给大家带来在 RT-Thread 遇到比较棘手的问题时候，快速解决问题的 "骚操作"了，废话不多说我们直接进入正题。
在 RT-Thread 上开发者除了线程使用最频繁之外一般就数 IPC 使用的最多了。信号量作为 IPC 中最基础和简单的一种, 是开发者爱不释手的一套开发逻辑的工具。那么笔者就在这里先简单说明下到底什么是信号量。
信号量是一种轻量的用于解决线程之间同步问题的内核对象，线程可以获取 (take) 或释放 (release) 它，从而达到同步或互斥的目的。以生活中的停车场为例来理解信号量的概念：
1. 当停车场空的时候，停车场的管理员发现有很多空车位，此时会让外面的车陆续进入停车场获得停车位；
2. 当停车场的车位满的时候，管理员发现已经没有空车位，将禁止外面的车进入停车场，车辆在外排队等候；
3. 当停车场内有车离开时，管理员发现有空的车位让出，允许外面的车进入停车场；待空车位填满后，又禁止外部车辆进入。
在这个例子中，管理员就相当于信号量， 管理员手中空车位的个数就是信号量的值，停车位相当于公共资源，正好与信号量的值匹配，车辆相当于线程。车辆通过获得管理员的允许取得停车位，就类似于线程通过获得信号量访问公共资源。
2. 不匹配使用信号量会带来什么问题
通过上面的例子我们能够简单的知道信号量是什么、有什么作用。既然这么好用，用的开发者这么多，相对来说也就会有很多人错误的使用信号量，导致带来各种各样的问题。
在这里我们借助上文使用过的停车场的例子来说明可能在什么情况下出现什么问题：
1. 车辆有进有出，车辆出的速度比车辆进的速度快，这种情况下停车场的位置永远都会有位置，这属于正常情况；
2. 车辆有进有出，车辆进的速度比车辆出的速度快，这种情况下停车场的位置永远都是满的，但是由于还是有车辆出后续的车辆还是有机会可以进去的。这也属于输入正常情况。
3. 车辆只进不出，这种情况下，最开始车位都是空的，最开始的几辆车可以正常进到停车场中，但是随着时间推移，车辆不会出去，总有一个时刻车位满了，那么外面的车都只有永远等着。这就属于异常情况了。
根据上面停车场的例子我们来总结下问题：
1. 信号量的使用需要匹配使用。
2. 信号量获取 (take) 后在短而确定的时间内需要释放 (release) 掉，如果时间过长，系统的实时性会降低。如果时间时长时慢，系统的稳定性会下降。
3. 如果信号量只获取不释放那么整个系统就会导致逻辑卡死。
3. 定位到底是 "谁" (thread) 只获取不释放
好了，终于到了重点了（前面的废话真难编，咳咳咳... 好像说了什么不该说的)。笔者在给大家说定位方法之前先在这里贴一段代码：
相信这段代码大家都能够看出问题所在，看不懂的，对不起出门右转(*^_^*)。
这段代码有个非常严重的问题，正常情况都是匹配使用，但是一但传入index大于2后就不会释放信号量，当没有其他的线程释放信号量的时候（只进不出）下次这个线程，获取其他线程需要获取这个信号量的时候就会 “逻辑卡死”。
其实很难避免这种代码的从来都不会出现，腿粗到没边的大神除外。那么作为非大神队列的我等普通人只有想办法出现这种问题后快速定位。
那么" 骚操作" 开始，这种问题难到我们的是：难以定位到底是在哪里没有释放，因为 RTOS 有多任务调用。那么我们换一种思路，我们不去找代码是在哪里没有释放的，我们先确定在“逻辑卡死”的情况下到底是哪个线程将这个线程持有的，缩小出问题的范围。
在现有的 RTT 内核代码中 IPC 只有保持阻塞线程队列，是没有保持持有线程队列的:????滑动查看全部
1struct rt_ipc_object
2{
3 struct rt_object parent; /**< inherit from rt_object */
4 rt_list_t suspend_thread; /**< threads pended on this resource */
5};
6
7struct rt_semaphore
8{
9 struct rt_ipc_object parent; /**< inherit from ipc_object */
10 rt_uint16_t value; /**< value of semaphore. */
11};
12typedef struct rt_semaphore *rt_sem_t;
那么我们来改造下内核代码，既然没有保存，那么我们来手动保持下，这里我们简化下，我们不保存获取线程的队列，我们只保持下最后一个获取的线程的线程名。
在 rtdef.h 文件中我们做如下改造：
????滑动查看全部
1struct rt_semaphore
2{
3 struct rt_ipc_object parent; /**< inherit from ipc_object */
4 char name[RT_NAME_MAX]; /**< name of take thread */
5 rt_uint16_t value; /**< value of semaphore. */
6};
7typedef struct rt_semaphore *rt_sem_t;
我们有地方存储这个名称变量了，那么我们还需要在获取时保持线程名，在 ipc.c 中做如下改造：
1rt_err_t rt_sem_take(rt_sem_t sem, rt_int32_t time)
2{
3 // ...
4
5 if (sem->value > 0)
6 {
7 /* semaphore is available */
8 sem->value --;
9
10 /* enable interrupt */
11 rt_hw_interrupt_enable(temp);
12
13 /* 保持线程名 */
14 rt_strncpy(sem->name, rt_thread_self()->name, RT_NAME_MAX);
15 }
16 else
17 {
18 /* no waiting, return with timeout */
19 if (time == 0)
20 {
21 // ...
22 }
23 else
24 {
25 // ...
26
27 /* reset thread error number */
28 thread->error = RT_EOK;
29
30 RT_DEBUG_LOG(RT_DEBUG_IPC, ("sem take: suspend thread - %s\n",
31 thread->name));
32
33 /* 获取不到信号量时，打印最后一次持有的线程的线程名 */
34 if(!rt_strncmp(sem->parent.parent.name, "heap", 4))
35 {
36 rt_kprintf("###### current last take sem thread: %s ######\n", sem->name);
37 }
38
39 /* suspend thread */
40 rt_ipc_list_suspend(&(sem->parent.suspend_thread),
41 thread,
42 sem->parent.parent.flag);
43
44 // ...
45 }
46 }
47
48 RT_OBJECT_HOOK_CALL(rt_object_take_hook, (&(sem->parent.parent)));
49
50 return RT_EOK;
51}
在上面代码我们可以看见，我们修改了2个地方：
1. 在信号量值 大于0 时，保持当前线程名，这样就可以永久将信号量句柄中的线程变量，保存为最后持有的线程的名字
2. 在信号量 =0 时，我们将持有线程的名字打印出来，这里笔者做了一个限制，我们只关注我们需要关注的信号量，所以做了个对比，非我们关注的信号量我们都不保持线程名，这样日志会变少。
到这一步我们就改造完毕日志了，将补丁打进 逻辑卡死 的工程中，等待打印：
1###### current last take sem thread: xxx ######
这样我们就缩小了问题出现的范围，接下来就需要分析到底线程那段代码卡死的了。互斥锁也可以使用这种方式确定问题出现在那个线程中。
4. 代码编写建议
容易漏掉释放一般都是函数推出位置不统一导致，可能今天写了不会缺少，过了几个月后再来写，添加了一个return就非常容易忘记释放信号量。
所以建议：函数最好是有统一出口，信号量的释放和获取最好都放到统一的出口处。
是不是很简单啊~(呃, 这个月笔者肚子中的墨水又干了，泡水恢复墨水去了)，嗯，就这样，我们下期再见~~~
E