发表于：2008/12/2 21:01:00
#0楼
关于程序死机的一点心得
borland c++，在ucos-ii多任务操作系统下，曾经遇到的死机复位问题，大家在编程时，如果遇到类似的问题，希望能有所帮助：
1、频繁操作文件，容易出现死机，操作文件时，最好关闭任务，操作完成后，再打开任务； uc/os-ii的osschedlock()和osschedunlock()函数应成对出现，允许应用程序锁定当前任务不被其它任务抢占。使用时应当注意的是：当你调用了osschedlock()之后，而在调用osschedunlock()之前，千万不要再调用诸如osflagpend()、osmboxpend()、osmutexpend()、osqpend()、ossempend()之类的事件等待函数！而且应当确保osschedlock()和osschedunlock()函数成对出现，特别是在有些分支条件语句中，要考虑各种分支情况，不要有遗漏！
2、任务优先级。每个任务都必须符合事件驱动的编程模型，即uc/os-ii的应用程序都必须是“事件驱动的编程模型”。一个任务首先等待一个事件的发生，事件可以是系统中断发出的，也可以是其它任务发出的，又可以是任务自身等待的时间片。当一个事件发生了，任务再作相应处理，处理结束后又开始等待下一个事件的发生。如此周而复始的任务处理模型就是“事件驱动的编程模型”。事件驱动模型也涵盖了中断驱动模型，uc/os-ii事件归根结底来自三个方面：
(1)中断服务函数发送的事件
(2)系统延时时间到所引起的
(3)其它任务发送的事件。
其中“中断服务函数发送的事件”就是指每当有硬件中断发生，那么中断服务程序就会以事件的形式告诉任务，而等待该事件的最高优先级任务就会马上得以运行；“系统延时时间到所引起的”事件其实也是硬件中断导致的，那就是系统定时器中断。而“其它任务发送的事件”则是由任务代码自身决定的，这是完全的“软事件”。不管“软事件”还是“硬事件”，反正引起uc/os-ii任务切换的原因就是“事件”，所以用户编写应用代码的时候一定要体现出“事件驱动的编程模型”。任务的优先级也一定要分配得当；
3、 零作为除数溢出后，死机，所以，要检查程序中是否有除零的地方；
4、查看堆栈是否满；
5、一些c语言函数，用到ucos-ii操作系统中，有时也可能出现问题，例如：gotoxy（）；printf（）；此项待进一步确定。
在网上也查看到一些司机原因：
os_enter_critical()和os_exit_critical()也可以用来保护应用程序中的临界代码；然而要特别小心，如果在调用一些如ostimedel()之类的功能函数之前关中断，应用程序将会死机；原因是任务被挂起一段时间，直到挂起时间到，但由于中断关掉了，时钟节拍中断一直得不到服务，显然所有的挂起类调用都有这样的问题，所以要特别小心。
需要一并提醒的是：当调用开关中断函数os_enter_critical()和os_exit_critical()时也要确保成对出现，否则系统将可能崩溃！不过，在os_enter_critical()和os_exit_critical()函数之间调用osflagpend()、osmboxpend()、osmutexpend()、osqpend()、ossempend()之类的事件等待函数是允许的。
希望大家把自己遇到的死机问题及解决方法写出来，供大家一起参考，我在此先谢谢了！
----------------------------------------------
此篇文章从博客转发
原文地址： Http://blog.gkong.com/more.asp?id=69795&Name=wuhongweizz
borland c++，在ucos-ii多任务操作系统下，曾经遇到的死机复位问题，大家在编程时，如果遇到类似的问题，希望能有所帮助：
1、频繁操作文件，容易出现死机，操作文件时，最好关闭任务，操作完成后，再打开任务； uc/os-ii的osschedlock()和osschedunlock()函数应成对出现，允许应用程序锁定当前任务不被其它任务抢占。使用时应当注意的是：当你调用了osschedlock()之后，而在调用osschedunlock()之前，千万不要再调用诸如osflagpend()、osmboxpend()、osmutexpend()、osqpend()、ossempend()之类的事件等待函数！而且应当确保osschedlock()和osschedunlock()函数成对出现，特别是在有些分支条件语句中，要考虑各种分支情况，不要有遗漏！
2、任务优先级。每个任务都必须符合事件驱动的编程模型，即uc/os-ii的应用程序都必须是“事件驱动的编程模型”。一个任务首先等待一个事件的发生，事件可以是系统中断发出的，也可以是其它任务发出的，又可以是任务自身等待的时间片。当一个事件发生了，任务再作相应处理，处理结束后又开始等待下一个事件的发生。如此周而复始的任务处理模型就是“事件驱动的编程模型”。事件驱动模型也涵盖了中断驱动模型，uc/os-ii事件归根结底来自三个方面：
(1)中断服务函数发送的事件
(2)系统延时时间到所引起的
(3)其它任务发送的事件。
其中“中断服务函数发送的事件”就是指每当有硬件中断发生，那么中断服务程序就会以事件的形式告诉任务，而等待该事件的最高优先级任务就会马上得以运行；“系统延时时间到所引起的”事件其实也是硬件中断导致的，那就是系统定时器中断。而“其它任务发送的事件”则是由任务代码自身决定的，这是完全的“软事件”。不管“软事件”还是“硬事件”，反正引起uc/os-ii任务切换的原因就是“事件”，所以用户编写应用代码的时候一定要体现出“事件驱动的编程模型”。任务的优先级也一定要分配得当；
3、 零作为除数溢出后，死机，所以，要检查程序中是否有除零的地方；
4、查看堆栈是否满；
5、一些c语言函数，用到ucos-ii操作系统中，有时也可能出现问题，例如：gotoxy（）；printf（）；此项待进一步确定。
在网上也查看到一些司机原因：
os_enter_critical()和os_exit_critical()也可以用来保护应用程序中的临界代码；然而要特别小心，如果在调用一些如ostimedel()之类的功能函数之前关中断，应用程序将会死机；原因是任务被挂起一段时间，直到挂起时间到，但由于中断关掉了，时钟节拍中断一直得不到服务，显然所有的挂起类调用都有这样的问题，所以要特别小心。
需要一并提醒的是：当调用开关中断函数os_enter_critical()和os_exit_critical()时也要确保成对出现，否则系统将可能崩溃！不过，在os_enter_critical()和os_exit_critical()函数之间调用osflagpend()、osmboxpend()、osmutexpend()、osqpend()、ossempend()之类的事件等待函数是允许的。
希望大家把自己遇到的死机问题及解决方法写出来，供大家一起参考，我在此先谢谢了！
----------------------------------------------
此篇文章从博客转发
原文地址： Http://blog.gkong.com/more.asp?id=69795&Name=wuhongweizz