2014-10-20 8 views
0

Я столкнулся с проблемой в нашем приложении на основе C, где один из VxWorks TASK (скажем, Task1) получил сбой по неизвестным причинам. В разбитой задаче был заблокирован семафор взаимного исключения (скажем, semA). Теперь следующий TASK2 ждет на semA, чтобы получить Unlocked. Поскольку semA заблокирован разбитой TASK, TASK2 будет бесконечно ждать, чтобы захватить semA. Это нарушило функциональность приложения.VxWorks Взаимозависимый семафор, заблокированный сбой TASK

Мы не можем предоставить таймаут для блокировки semA в TASK2, потому что semA защищает маршрутизацию отправки, которая отправляет данные через сокеты. Предоставление тайм-аута приведет к сбою в передаче сообщений.

После поиска в Интернете я нашел ROUTE MUTEX для LINUX для такой проблемы, но наша платформа VxWorks (версия 5.5.1). Так может кто-нибудь сказать мне, как мы справимся с этой проблемой в VxWorks?

Я попытался использовать гайку, указанную ниже, но не уверен, насколько это безопасно.

1) TASK2 будет ждать на SEMA для конкретного timout 2), если не удалось проверить состояние предыдущей задачи, которые заперли SEMA 3, если TASK1 состояния SUSPENDED, ЗАДАЧА 2 будет называть semDelete на SEMA и чем воссоздать его , 4) если TASK1 не находится в состоянии SUSPENDED, продолжайте ждать, чтобы схватить semA.

У меня есть тестовый код в качестве прототипа и работает нормально. Я не уверен, насколько хорошо реализовать такое решение, где мы воссоздаем семафор и какие возможные риски могут возникнуть.

Пожалуйста, дайте мне знать ваши данные.

Благодаря

ответ

1

Я думаю, что ваше решение не прототип больше рискованное, чем иметь код (TASK1), что сбой по неизвестным причинам.

Если бы я работал над вашей проблемой, я бы сначала попытался очень сильно узнать, почему Task1 рушится. Если бы я не смог понять основную причину, я бы пошел на реализацию вашего предлагаемого решения. То есть, я запрошу состояние Task2 через определенное время, а затем воссоздаю семафор.

0

Я должен сказать, что даже если вы реализуете свою работу по воссозданию семафора, у вас все еще есть разбитая задача, которая потребляет ресурсы. Если эта проблема не исчезнет, ​​тогда вся система перестанет работать. В конце концов, правильный и единственный способ исправить эту проблему - исправить ошибку в task1. Вы должны иметь возможность получить трассировку стека, где она разбилась, и исправить ее.

0

Вторые предыдущие ответы: поиск причины сбоя Task1 лучше, чем реализация обходного пути.

Можете ли вы опубликовать сообщения, написанные VxWorks разбитой Task1?

Одна из первых вещей, которые я пытаюсь выполнить, если задача сбой по какой-либо причине - увеличить размер стека (допустим, удвоить его). Если задача выполняется нормально, размер стека слишком мал. Также попробуйте увеличить размер стека задач (задач), которые вы изменили в последнее время!

Если это проблема стека, это не обязательно Task1, которая виновата ...

+0

1e1fab4 vxTaskEntry +68: SpyThread() caee04 SpyThread + 1A0: SpyThreadProcessMsg() caea30 SpyThreadProcessMsg + 134: Send2Client() cb4f50 Send2Client +378: MiSslWrite (1515ee09, е0, 1328532c) 89aa8c MiSslWrite +74: SSL_write() 88c98c SSL_write + 50: ssl3_write (1515ee09, е0, 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) ******* Ассемблер сбоев c ode Dump ******* – Abhishek

 Смежные вопросы

  • Нет связанных вопросов^_^