메시지 큐는 Linux에서 더 이상 사용되지 않습니까?

Question

나는 최근에 리눅스에서 메시지 큐 (System V,하지만 POSIX도 괜찮아 야 함)를 사용 해왔다. 그리고 그들은 내 응용 프로그램에 완벽하게 보일 것이다. 그러나 The Art of Unix Programming을 읽은 후에 나는 그들이 정말로 좋은 선택.

http://www.faqs.org/docs/artu/ch07s02.html#id2922148

V IPC 시스템의 상부, 메시지 전달 층

주로 사용으로 떨어졌다. 공유 메모리와 세마포어로 구성된 하위 계층은 동일한 컴퓨터에서 실행되는 프로세스간에 상호 배제 잠금 및 일부 전역 데이터 공유를 수행해야하는 상황에서 중요한 응용 프로그램을 보유하고 있습니다. 이 System V 공유 메모리 기능은 Linux, BSD, MacOS X 및 Windows에서 지원되지만 POSIX 공유 메모리 API로 발전했지만 고전적인 MacOS는 아닙니다. http://www.faqs.org/docs/artu/ch07s03.html#id2923376

시스템 V IPC 시설

는 리눅스와 다른 현대 유닉스에 존재한다. 그러나, 그들은 유산 기능이기 때문에, 아주 자주 운동하지 않습니다. Linux 버전은 2003 년 중반 현재까지 버그가있는 것으로 알려져 있습니다. 아무도 그들을 돌볼만큼 신경 쓰지 않는 것 같습니다.

최근 버전의 Linux에서 System V 메시지 대기열이 여전히 버그가 있습니까? 저자가 POSIX 메시지 대기열이 괜찮다는 것을 의미하는지 확신 할 수 없습니까?

소켓이 거의 모든 것 (?)에 대해 선호되는 IPC 인 것으로 보이지만 소켓이나 다른 것으로 메시지 대기열을 구현하는 것이 얼마나 간단한 지 알 수 없습니다. 아니면 너무 복잡하게 생각하고 있습니까?

내가 임베디드 리눅스와 관련이 있는지는 모르겠다.

Answer 1

개인적으로 저는 메시지 대기열이 상당히 좋아서 유닉스 세계에서 가장 많이 활용되지 않은 IPC라고 생각합니다. 그들은 빠르고 사용하기 쉽습니다.

생각을 몇 :

• 이 중 일부는 패션입니다. 오래된 것들은 다시 새롭게됩니다. 메시지 대기열에 반짝 반짝 빛나는 할아버지를 추가하면 내년 가장 새롭고 가장 뜨거운 일이 될 것입니다. 탭 대신 스레드가 아닌 별도의 프로세스를 사용하여 Google 크롬을 살펴보세요. 갑자기 한 사람의 탭이 잠길 때 브라우저 전체가 파괴되지 않는다는 사실에 사람들은 감탄하고 있습니다.

• 공유 메모리에는 He-man halo가 있습니다. 머신에서 마지막 사이클을 쥐어 짜지 않고 MQ의 성능이 약간 떨어지는 경우 "진짜"프로그래머가 아닙니다. 대부분의 앱이 아니라면 많은 사람들에게 말도 안되는 말이지 만 때로는 일단 잡히면 마인드를 깨뜨리는 것이 어렵습니다.

• MQ는 실제로 무제한 데이터가있는 응용 프로그램에는 적합하지 않습니다. 파이프 나 소켓과 같은 스트림 지향 메커니즘은이를 사용하기 쉽습니다.

• System V 변종은 실제로 선호하지 않습니다. 가능한 한 POSIX 버전의 IPC를 사용하는 것이 일반적입니다.

Answer 2

필자는 네트워크를 통해 메시지를 배포하는 옵션을 항상 열어두기 위해 POSIX 메시지 대기열을 실제로 사용하지 않았습니다. 이를 염두에두고 zeromq 또는 AMQP과 같은보다 강력한 메시지 전달 인터페이스를 살펴볼 수 있습니다.

0mq에 대한 좋은 점 중 하나는 멀티 스레드 응용 프로그램의 동일한 프로세스 공간에서 사용될 때 매우 빠른 잠금없는 제로 복사 메커니즘을 사용한다는 것입니다. 그래도 동일한 인터페이스를 사용하여 네트워크를 통해 메시지를 전달할 수 있습니다.

Answer 3

예, 일부 응용 프로그램에는 메시지 대기열이 적절하다고 생각합니다. POSIX 메시지 대기열은 더 멋진 인터페이스를 제공합니다. 특히 ID가 아닌 대기열 이름을 제공하므로 오류 진단에 매우 유용합니다 (어떤 것이 더보기 쉬운지).

리눅스는 posix 메시지 대기열을 파일 시스템으로 마운트하고 "ls"로 볼 수 있으며, "rm"으로 삭제할 수 있습니다 (System V는 "ipcs"및 "ipcrm"명령에 의존합니다.))

POSIX 메시지 큐의

Answer 4

가장 큰 단점 :.

• POSIX 메시지 큐는이 요구 사항이 select()와 호환되도록하지 않습니다 (그것은 QNX 시스템에서 리눅스에 select()와 함께 작동하지만)
• 놀라운 일이 있습니다.

유닉스 데이터 그램 소켓은 POSIX 메시지 큐와 동일한 작업을 수행합니다. 유닉스 데이터 그램 소켓은 소켓 계층에서 작동합니다. select()/poll() 또는 다른 IO 대기 메소드와 함께 사용할 수 있습니다. select()/poll()을 사용하면 이벤트 기반 시스템을 설계 할 때 이점이 있습니다. 그런 식으로 통화 중 루프를 피할 수 있습니다.

메시지 대기열에 놀람이 있습니다. mq_notify()에 대해 생각해보십시오. 수신 이벤트를받는 데 사용됩니다. 메시지 대기열에 대해 알릴 수있는 것 같습니다. 그러나 실제로 알림을 보내는 대신 알림을 등록합니다.

더 놀라운 약 mq_notify()는 경쟁 조건이 발생할 수있는 모든 mq_receive() 후에 호출해야한다는 것입니다 (시 mq_receive() 및 mq_notify()의 호출 사이에 다른 프로세스/스레드 호출 mq_send()).

그리고 중복되는 경우가 있고 open(),send(),recv() and close() 소켓 사양과 일치하지 않는 자체 정의가있는 의 전체 세트가 있습니다.

동기화를 위해 메시지 대기열을 사용해야한다고 생각하지 않습니다. eventfd 및 signalfd이 적합합니다.

그러나 실시간 지원이 있습니다. 우선 순위 기능이 있습니다.

그러나이 우선 순위는 소켓에서 대역 외 데이터로도 사용할 수 있습니다.

마지막으로, 저에게 POSIX 메시지 큐는 레거시 API입니다. 필자는 항상 POSIX 메시지 큐 대신 Unix Datagram 소켓을 선호합니다.