QNX RTOS: 6-2. IPC 선택 기준

IPC 메커니즘 선택 기준 정리

1. POSIX 준수(POSIX compliance)가 요구사항인가?

• 예: 코드 이식성(portability)이 중요하거나
  • 소스 공유, 오픈소스 적용, 여러 OS에서 재사용 필요
    → POSIX 메커니즘(signals, shared memory, pipes, POSIX MQ, sockets 등) 위주로 선택
• 아니오: QNX 전용 최적화/실시간성 우선
  → QNX Native(MsgSend/Receive/Reply, Pulse 등) 적극 고려

---

2. 이동하는 데이터 크기(data volume)는 얼마나 큰가?

• 대용량 데이터(large payload):
  • 복사(copy) 횟수를 최소화해야 함
    → Shared Memory 우선 고려 (copy-free)
  • 단, 설계에 따라 QNX 메시지(QNX messages)도 충분히 효율적일 수 있음
• 소량/이벤트성 데이터(tiny payload):
  → Pulse(펄스) 적합 (작은 데이터 + 비차단 알림)

---

3. 즉시 응답(direct response)이 필요한가? 즉, block을 감수할 수 있는가?

• 응답 필요 / block 가능:
  → QNX 메시지(RPC형)가 가장 자연스러움
  (Client가 Reply까지 block → 동기화 포함)
• 응답 불필요 / sender가 계속 실행해야 함(non-blocking 필요):
  → Pulse / Signal 같은 비차단 알림 방식 고려

---

4. 버퍼링(buffering) 설계를 직접 할 의사가 있는가?

질문 의도: “극단 상황(예: low memory)에서도 예측 가능한 동작을 보장해야 하는가?”

• 예 (직접 통제하고 싶다):
  • 초기(pre) 할당, 고정 크기 풀(pool), worst-case 관리 가능
    → 프로그래머가 버퍼링 정책을 설계 가능한 방식 선호
• 아니오 (내장 큐/버퍼에 맡긴다):
  • POSIX MQ, pipe 등도 사용 가능하지만,
  • 실시간/안전(safety) 요구가 강하면 선택이 제한될 수 있음

---

5. 안전 인증(safety certified) 요구가 있는가?

• 예: 안전 인증 요구가 있으면
  → 일반 POSIX 메커니즘보다 QNX에서 안전 인증된(혹은 안전 사용 가이드가 명확한) 방식을 우선 고려하도록 유도될 수 있음
• 아니오: 기능/이식성 중심으로 폭넓게 선택 가능

---

6. 네트워크를 넘어 통신해야 하는가(cross-network)?

• 예:
  → 사실상 TCP/IP sockets로 수렴
  (로컬/원격 동일 서비스 제공 필요 시 특히 유용)
• 아니오:
  → 로컬 IPC는 QNX 메시지/펄스/공유메모리 조합이 보통 더 효율적

---

7. 메커니즘을 조합(combination)할 수 있는가?

현실적인 결론: 하나로 끝나는 경우는 드물고, 조합이 일반적.

대표 조합 패턴:

• 제어(control)는 메시지, 데이터(data)는 공유메모리
  • 예: MsgSend로 “버퍼 N번 처리해라” 전달 + Shared Memory에 대용량 payload 저장
• 이벤트는 펄스, 상세 데이터는 메시지/공유메모리
  • Pulse로 wakeup → client가 MsgSend로 상세 요청

---

최종 요약

IPC 선택은 (1) POSIX 필요성, (2) 데이터 크기/복사 비용, (3) block 가능 여부(응답 필요성), (4) 버퍼링 통제/안전 요구, (5) 네트워크 필요성, (6) 조합 설계 가능성을 기준으로 결정한다.