vxworks异常调度观察

时间:2013-04-27 02:11:46

标签: vxworks

我在系统中看到一些不寻常的东西。我的一个应用程序任务'xxxx'对于信号量是“待定”的。它的优先级是94,低于tt。

This task is pending:
(de009e8)   329220 vxTaskEntry +5c: yyyy()
....
(de003a8)  1453384 aaaaaa +3fc: fdprintf()
(de00328)   37ea54 fdprintf +60: fioFormatV()
(de00100)   37f0ac fioFormatV +4f0: fioFormatV()
(de000e8)   37fb44 fioFormatV +f88: write()
(de000c8)   383218 write +50: iosWrite()
(de00050)   385218 iosWrite +d0: tyWrite()
(de00028)   394d80 tyWrite +60: semTake()
(de00008)   3de698 semTake +90: semBTake()

Sem Id: 0xf7dfa40  BINARY EMPTY Owner: 0x7a42e78 (yyyy)
Pended Tasks:   xxxx @ 94

但是任务yyyy的tt如下所示。这里最重要的一点是,此任务处于“就绪”状态。此任务的优先级为100。

<This task is ready>
(7a42e18)   329220 vxTaskEntry +5c: gggg()
....
(7a42cd8)   37e590 printf +84: fioFormatV()
(7a42ab0)   37fab8 fioFormatV +efc: fioFormatV()
(7a42a98)   37fb44 fioFormatV +f88: write()
(7a42a78)   383218 write +50: iosWrite()
(7a42a00)   385218 iosWrite +d0: devConsCreate()
(7a429e8)   127a18 devConsCreate +f8: write()
(7a429c8)   383218 write +50: iosWrite()
(7a42950)   385218 iosWrite +d0: tyWrite()
(7a42928)   394d80 tyWrite +60: semTake()
(7a42908)   3de698 semTake +90: semBTake()

当'yyyy'本身在semBtake()处于就绪状态时,任务'xxxx'如何才能获得由'yyyy'拥有的信号量?

2 个答案:

答案 0 :(得分:0)

仅仅因为任务准备好运行,并不意味着它实际上正在运行......在这种情况下:

  1. yyyy任务首先获得了信号量
  2. 任务yyyy可能被其他具有更高优先级的东西抢占(例如shell或任务xxxx)
  3. 任务xxxx尝试获取信号量但被阻止因为yyyy已经拥有它
  4. 最终任务yyyy实际上会进一步运行直到它释放信号量
  5. 当任务yyyy释放信号量时,xxxx任务将立即被解除阻塞并运行...

答案 1 :(得分:0)

由于您有两个任务采用相同的信号量,因此我假设您使用信号量来保护使用共享资源的代码的关键部分。这些假设可能不正确,如果是这样,请告诉我们。

您可能正在处理无限优先级倒置。任务yyyy已采取信号量,任务xxxx正在等待并等待信号量。任务yyyy没有在处理器上执行,因为系统中有一个更高优先级的任务在94和100之间(无界优先级倒置)或甚至高于94(正常更高优先级任务干扰)正在使用CPU并且不允许任务yyyy执行完成。

如果这一切都是真的,您可能需要考虑用具有优先级继承的Mutex替换二进制信号量。一旦任务XXX在互斥锁上开始挂起,这将导致任务YYYY优先级暂时升级到94以匹配任务XXXX。因此,当任务XXXX请求互斥锁时,阻止优先级94和100之间的任何任务执行。

如果优先级94以上的任务没有放弃处理器,则需要查看整个系统以及该任务的实现方式,并确定是否需要更改某些内容以便允许其他优先级较低的任务时间在CPU上执行。