VxWorks互斥信號量被鎖死的TASK鎖定

我在我們基於C的應用程序中遇到了一個問題，其中VxWorks TASK之一（比如Task1）由於某些未知原因而崩潰。崩潰的任務鎖定了互斥信號量（比如semA）。現在下一個TASK2正在等待semA以獲得解鎖。由於semA被一個崩潰的TASK鎖定，因此TASK2將無限等待以獲取semA。這已破壞應用程序功能。VxWorks互斥信號量被鎖死的TASK鎖定

我們無法提供超時來鎖定TASK2中的semA，因爲semA正在保護通過套接字發送數據的發送路由。提供超時將導致消息通信失敗。

谷歌搜索後，我發現LINUX的ROBUST互斥這個問題，但我們的平臺是VxWorks（版本5.5.1）。那麼有人能告訴我在VxWorks中如何處理這個問題嗎？

我已經嘗試了下面提到的解決方案螺母，不知道它是如何安全的。

1）TASK2將等待SEMA因爲如果失敗檢查已經鎖定的SEMA前一個任務的狀態的特定timout 2） 3如果TASK1狀態被暫停，任務2將拜會SEMA semDelete比重新創建。 4）如果TASK1不處於SUSPENDED狀態，繼續等待抓取semA。

我已經測試這個代碼爲原型，工作正常。我不確定在我們重新創建信號量的情況下實施這樣的解決方案有多好，以及可能帶來的風險是什麼。

請讓我知道您的意見。

感謝

來源

2014-10-20 Abhishek

我覺得你的原型的解決方案並不比具有崩潰原因不明代碼（任務1）風險了。

如果我要解決您的問題，我會先嚐試確定Task1崩潰的原因。如果我無法找出根本原因，那麼我會去實施你提出的解決方案。也就是說，我會在一段時間後查詢Task2的狀態，然後重新創建信號量。

來源

2014-10-21 20:08:35 stu

我必須說，即使你實現了重新創建信號量的工作，那麼你仍然有一個崩潰的任務會消耗資源。如果這個問題依然存在，那麼最終整個系統將停止工作。最終解決此問題的正確方法是解決task1中的崩潰問題。你應該能夠得到一個堆棧跟蹤到崩潰的地方並修復它。

來源

2014-10-25 08:31:27

我第二次回答以前的答案：找到原因爲什麼Task1崩潰比實施一個解決方法更好。

你可以發佈由VxWorks寫的崩潰Task1的消息嗎？

如果一個任務崩潰沒有很好的理由，我嘗試的第一件事就是增加它的堆棧大小（讓我們把它加倍）。如果任務運行正常，則堆棧大小太小。同時嘗試增加最近修改的任務的堆棧大小！

如果這是一個堆棧問題，它不是必須Task1這是怪...

來源

2014-10-26 19:55:32

1e1fab4 vxTaskEntry 68：SpyThread（） caee04 SpyThread + 1A0：SpyThreadProcessMsg（） caea30 SpyThreadProcessMsg + 134：Send2Client（） cb4f50 Send2Client 378：MiSslWrite（1515ee09，E0，1328532c） 89aa8c MiSslWrite 74：SSL_write （） 88c98c SSL_write 50：ssl3_write（1515ee09，E0，1328532c） 884968 ssl3_write 100：ssl3_write_bytes（E0，17，1328532c，1515ee09） 8865e4 ssl3_write_bytes + D8：886658（1328532c，17，61a6628） 8867b8 ssl3_write_bytes + 2ac：886658（1328532c，17，61a6628） 8868e8 ssl3_write_bytes + 3dc：tls1_enc（1328532c） ******* Crash Assembler c Ode轉儲******* – Abhishek 2014-10-29 05:20:09

VxWorks互斥信號量被鎖死的TASK鎖定

回答

相關問題