vxworks 메시지 큐가 차단 된 작업을 "손실"했습니다. 이유가 무엇일까요?

Question

우리는 Vxworks 5.5 및 PPC8260에 구현 된 매우 큰 멀티 태스킹 통신 시스템을 보유하고 있습니다. 시스템은 많은 이더넷 트래픽을 처리해야하며 또한 RS-232, 메모리 매핑 I/O 등을 통해주기적인 주변 장치 제어 작업을 처리해야합니다. 어떤 순간에 우리는 작업 간 통신을 위해 사용하는 몇 가지 메시지 대기열이 오버플로됩니다 로그 검사를 참조하십시오). 이 메시지 대기열에 대한 책임이있는 작업의 상태를 확인할 때 대기열에 대한 msgQShow를 검사 할 때 대기 상태이지만 대기중인 작업은 차단 된 것으로 보입니다. 그러나 작업 스택 추적을 보면 실제로 msgQReceive 내부에서 보류중인 작업이 표시됩니다. 특히 qJobGet 커널 호출 또는 비슷하게 작동합니다.

Answer 1

메시지 큐가 차단 된 작업을 "잃어 버렸다"는 극단적 인 경우는 거의 없습니다. 당신의 설명에서

우리는 가정 할 수 있습니다 :

1. 메시지 대기열이 초과되었습니다. 아마도 시간 초과 값 또는 NO_WAIT로 호출 된 msgQSend의 리턴 값을 검사하여이를 감지했을 것입니다.
2. msgQShow는 Q가 가득 찼음을 확인합니다.
3. 대기열을 읽어야하는 작업은 준비 상태입니다.

READY 상태는 작업을 실행할 수있는 상태입니다. 작업은 대기열 (엄격하게는 우선 순위 수준 당 하나의 대기열)에 보관되며 대기열의 머리에 도달하면 대기열에 있습니다.

작업이 READY로 지속적으로 표시되면 CPU 시간을 얻지 못했음을 나타냅니다. msgQ가 비어있는 것처럼 보이지 않는다는 사실은 이것을 지원합니다.

시스템 뷰어와 같은 도구를 사용하여 진단해야합니다. 리더 작업의 우선 순위를 높여야 할 수도 있습니다. 당신의 msgQSend가 NO_WAIT을 사용한다면, 우선 순위가 높은 태스크가`qJobGet`에서 실행을 막는 작업을 방해 할 수있는 가능성이 있으니 시간 제한 값