TOC\o"1-3"\h\zHYPERLINK\l"_Toc69095936"技术讲座PAGEREF_Toc69095936\h1HYPERLINK\l"_Toc69095937"引用记数技术PAGEREF_Toc69095937\h1HYPERLINK\l"_Toc69095938"死锁问题PAGEREF_Toc69095938\h1HYPERLINK\l"_Toc69095939"使用读写锁PAGEREF_Toc69095939\h3HYPERLINK\l"_Toc69095940"任务优先级继承PAGEREF_Toc69095940\h3HYPERLINK\l"_Toc69095941"栈调用顺序PAGEREF_Toc69095941\h3HYPERLINK\l"_Toc69095942"怎样反汇编对应你的C/C++代码在Vxworks中.PAGEREF_Toc69095942\h5技术讲座引用记数技术供多线程使用的数据结构应该采用引用计数（referencecounts）。在内核中，垃圾回收（garbagecollection）是不存在的（内核之外的垃圾回收效率不高），这意味着你_必须_使用引用计数。引用计数的使用能避免锁的使用，使不同的用户能够并行使用数据结构-不需要担心结构会因为睡眠而突然消失。注意到加锁_不是_引用计数的替代物。加锁用于保证数据结构的完整性，而引用计数是一个内存管理技术。通常你两个都需要，不应该有任何混淆不清的地方。一些数据结构可能使用两层的引用计数，当对不同的“类”都有使用的时候。子类的计数统计所有子类用户的数目，当子类的计数为零时只对总计数减一。这种“多层引用计数”的例子可以在内存管理代码（“structmm_struct”：mm_users和mm_cout）和文件系统代码（“structsuper_block”：s_count和s_active）中找到。比如MFCCstring。记住：如果另一个线程能够看见你的数据结构，而你却没有对它使用引用计数，那么几乎可以肯定会有bug存在。死锁问题在设计复杂的程序时，涉及到多线程，多个全局变量时，很容易掉入死锁。死锁发生：双方都等待对方去释放资源。一般，死锁分为两种，1>资源型2>消息型，，比如在vxWorks两个任务各自向对方的消息队列中发消息.下面简述一下产生死锁的必要条件：如果在在你的程序代码中，同时具备下面四个必要条件时，那么会发生死锁。换句话说，只要下面四个条件中有一个不具备，系统就不会出现死锁。1．互斥条件：即某个资源在一段时间内只能由一个进程(线程/任务)占有，不能同时被两个或两个以上的进程占有。2．不可抢占条件：进程（线程/任务）所获得的资源在未使用完毕之前，资源申请者不能强行地从资源占有者手中夺取资源，而只能由该资源的占有者进程自行释放。3．占有且申请条件：进程（线程/任务）至少已经占有一个资源，但又申请新的资源；由于该资源已被另外进程占有，此时该进程阻塞；但是，它在等待新资源之时，仍继续占用已占有的资源。4．循环等待条件：存在一个进程（线程/任务）等待序列{P1,P2,…,Pn},其中P1等待P2所占有的某一资源，P2等待P3所占有的某一资源，……，而Pn等待P1所占有的某一资源，形成一个进程循环（线程/任务）等待环。死锁的有向图表示面我们提到的这四个条件在死锁时会同时发生。也就是说，只要有一个必要条件不满足，则死锁就可以排除。处理死锁的基本方法可归结为以下3种：>打断死锁>使用锁时，最好有超时等待，并判断返回值。>在读写情况很多的条件下,建议使用读写锁。在有可能的情况下，使用读写锁，而不要总是使用互斥锁；对读写排序，使用原子操作，从而完全避免使用锁，也是一个不错的设计思想。使用读写锁当我们要对某一公用数据区进行多线程的读写操作时，我们经常使用的是Mutex,Semphore。这样当两个线程同时对这一公用数据区进行读操作时，也需要相互等待。事实上我们可以看出，这种等待是没有必要的。从这一概念出发，我们把对这种操作所需要的锁称之为“读写锁”。读写锁允许多个线程同时进行读操作，但一个时间至多只有一个线程进行写操作。读写锁可以明显改进程序的性能，在Solaris中，有读写锁的系统调用，而在vxworks中，没有。所以我觉得有必要实现这一读写锁。任务优先级继承栈调用顺序在分析一个栈的内容时，你必须记下列的常识１>在通常的编译器设计中，栈的顺序总是从高到低２>栈保存的内容：函数参数，下一条指令的地址，上一个函数的栈基地址，