양방향 스레드 간 통신에 ZMQ 사용

Question

저는 ZeroMQ를 처음 사용합니다. 지난 몇 달 동안 문서를 읽고 라이브러리를 실험 해 보았습니다. 현재 멀티 스레드 C++ 응용 프로그램을 개발 중이며 뮤텍스 대신 ZeroMQ를 사용하여 메인 스레드와 해당 자식간에 데이터를 교환하려고합니다.

하위 스레드가 외부 응용 프로그램과의 통신을 처리하고 있습니다. 따라서 메인 스레드와 그 자식 사이에/소켓을 대기시켜야합니다. 하나는 발신 메시지 용이고 다른 하나는 수신 메시지 용입니다.

이를 위해 어떤 zmq 소켓을 사용해야합니까? ZeroMQ를 사용하여 공유 메모리와 뮤텍스를 사용하여 이동하면서 미리

Answer 1

에서

감사합니다, 당신은 배우 모델 프로그래밍의 영역에 진입하고 있습니다.

제 생각에 이것은 상당히 좋은 것입니다. 그러나 몇 가지 사항을 알고 있어야합니다.

1. 뮤텍스가 더 이상 필요하지 않은 이유는 데이터를 공유하지 않고 복사하기 때문입니다. '비용'은 공유 데이터를 가리키는 뮤텍스를 잠그는 것보다 많은 양의 데이터를 복사하는 것이 훨씬 오래 걸리는 것입니다. 따라서 공유 메모리/뮤텍스를 사용하는 동등한 프로그램과 비교하여 개처럼 실행되는 멋진 찾고 액터 모델 프로그램으로 끝낼 수 있습니다.
2. Intel Xeons와 같이 CPU가 여러 개인 복잡한 아키텍처에서는 공유 메모리에 액세스 할 때 복사하는 것처럼 생각할 수 있습니다. 이는 QPI 버스에서의 트랜잭션을 의미 할 수 있기 때문입니다. 액터 모델 프로그래밍은 NUMA 하드웨어 아키텍처에 이상적입니다. 최신 Intel 및 AMD 아키텍처는 부분적/근본적으로 NUMA이지만 QPI/Hypertransport를 통해 실행되는 프로토콜은 SMP 환경을 "위장"합니다.
3. 실용적인 곳에서는 ZMQ_PAIR 소켓을 피할 것입니다. 네트워크 연결을 통해 작동하지 않습니다. 즉, 어떤 이유로 든 응용 프로그램을 여러 컴퓨터에서 확장해야하는 경우 코드를 다시 작성해야합니다. 그러나 처음부터 다른 소켓 유형을 사용하는 경우 응용 프로그램을 확장하면 코드를 변경하지 않고 코드를 다시 배포해야합니다. FYI nanomsg PAIR에는 이러한 제한이 없습니다.
4. 잠시 동안 배우 모델 프로그래밍이 모든 문제를 해결할 것이라고 가정하지 마십시오. 그것은 모든 문제를 가지고 있습니다. 여전히 교착 상태, 라이브 록, 스핀 락 (spin lock) 등을 할 수 있습니다. Actor 모델 프로그램의 문제점은 언젠가 네트워크가 조금 더 바 빠질 때까지 이러한 문제가 몇 년 동안 코드에 숨어있을 수는 없다는 것입니다. 실행을 멈춘다 ...
5. 그러나 "Communicating Sequential Processes"라는 액터 모델 프로그래밍이 개발 중입니다. 이것으로는 문제를 해결할 수 없지만 이러한 문제로 프로그램을 작성한 경우 매번 발생하는 것이 보장됩니다. 따라서 개발 및 테스트 중에 문제를 발견하게됩니다. 5 년 후 아닙니다. 또한 프로세스 계산법이 있습니다. 즉, 한 줄의 코드를 작성하기 전에 디자인에 문제가 없다는 것을 대수적으로 증명할 수 있습니다. ZeroMQ는 CSP가 아닙니다. 흥미롭게도 CSP는 복귀의 무언가를 만들고 있습니다. Rust와 Go 언어는 모두 CSP입니다. 그러나 네트워크 연결을 통해 CSP를 수행하지는 않습니다. 이는 모두 진행중인 작업입니다. Erlang은 CSP도 수행하며 AFAIK는 네트워크 연결을 통해이를 수행합니다.
6. CSP에 대한 모든 내용을 읽고 여전히 ZeroMQ를 사용한다고 가정하면 ZeroMQ 소켓을 통해 전송할 계획이 무엇인지 신중히 생각하십시오. 같은 시스템에있는 하나의 프로그램 내에 모두있는 경우 정수 배열 등의 사본을 보내는 것이 좋습니다. 그들은 여전히 ​​수신단에서 정수로 해석 할 수 있습니다.그러나 ZMQ 소켓을 통해 다른 컴퓨터로 데이터를 전송하려는 열망이 있다면 일종의 직렬화 기술을 고려해 볼 가치가 있습니다. ZeroMQ는 메시지를 전달합니다. 왜 그 메시지를 객체 직렬 자의 바이트 스트림으로 만들지 않습니까? 그런 다음 수신 된 메시지가 디시 리얼 라이 제이션 후에 수신 측에서 적절한 것을 의미하도록 보장 할 수 있습니다.
7. 나를 위해 좋아하는 직렬 장치에는 Google 프로토콜 버퍼가 포함됩니다. 이기종 시스템에 대해 많은 옵션을 제공하는 언어/운영 체제에 무관합니다. ASN.1은 또 다른 훌륭한 옵션 중 하나입니다. 중요한 언어의 대부분을 차지할 수 있으며, XML 및 현재/곧 JSON을 비롯한 여러 가지 유선 형식의 세트가있어 흥미로운 상호 운용 옵션을 제공합니다. Constraints (Google PBufs가하지 않는 것)를 수행하지만 실제로 좋은 도구가 필요한 경우 비용이 드는 경향이 있습니다. XML은 거의 모든 것으로 이해 될 수 있지만 비 대한입니다. 기본적으로 C#이나 파이썬을 사방에 사용하지 않는 것이 좋습니다.

행운을 빈다.