사용할 Linux IPC 기술은 무엇입니까?

우리는 아직 프로젝트의 설계 단계에 있지만 임베디드 리눅스 커널에 대해 세 가지 별도의 프로세스가 필요하다고 생각하고 있습니다. 프로세스 중 하나는 다양한 매체를 통해 장치와의 모든 통신을 처리하는 통신 모듈입니다.사용할 Linux IPC 기술은 무엇입니까?

다른 두 프로세스는 통신 프로세스를 통해 메시지를 보내고받을 수 있어야합니다. Linux가 제공하는 IPC 기술을 평가하려고합니다. 다른 프로세스가 전송할 메시지는 ~ 5Mbit 속도로 디버그 로그에서 스트리밍 미디어까지 크기가 다양합니다. 또한 미디어가 동시에 스트리밍되고 스트리밍 될 수 있습니다.

이 응용 프로그램에 어떤 IPC 기법을 제안하겠습니까? http://en.wikipedia.org/wiki/Inter-process_communication

프로세서가 변경되면 약 400-500MHz가 실행됩니다. 크로스 플랫폼 일 필요는 없습니다. 리눅스 만 괜찮습니다. C 또는 C++ 로의 구현이 필요합니다.

출처

2010-02-17 RishiD

+23

리눅스 커널은 다음과 같은 IPC 메커니즘을 제공합니다 , POSIX 세마포어, 퓨 텍스 잠금 장치, 파일 백업 및 익명 공유 메모리 사용의 mmap, UNIX 도메인 소켓, NETLINK 소켓, 네트워크 소켓, inotify를 메커니즘 s, 퓨즈 서브 시스템, D-Bus 서브 시스템. 대부분의 나의 필요를 위해 나는 소켓을 사용한다. – enthusiasticgeek

@enthusiasticgeek D-Bus는 사용자 공간에서 전적으로 수행됩니다. 일부 커널 녀석은 [kdbus] (https://github.com/gregkh/kdbus)에서 작업하고 있지만 여전히 진행중입니다. – new123456

arm926ejs 200MHz 프로세서에서 두 개의 uint32 인수를 사용하는 메서드 호출과 응답은 0에서 15ms 사이의 어느 곳에서든지 소모합니다. 평균 6 ms. 다른 사람들이 다른 프로세서에서 어떻게 볼 수 있습니까? – minghua

나는 유닉스 도메인 소켓을 원한다. 즉, IP 소켓보다 오버 헤드가 적다.

출처

2010-02-17 14:01:09 jldupont

"고전적인"Linux IPC 메커니즘에 대한 설명은 here을 참조하십시오.

출처

2010-02-17 14:03:15

IPC를 선택할 때 전송 버퍼 크기, 데이터 전송 메커니즘, 메모리 할당 스키마, 잠금 메커니즘 구현 및 코드 복잡성과 같은 성능 차이의 원인을 고려해야합니다.

사용 가능한 IPC 메커니즘 중에서 성능에 대한 선택은 종종 Unix domain sockets 또는 named pipes (FIFOs)입니다. IPC 용 Unix 도메인 소켓이 최상의 성능을 제공 할 수 있음을 나타내는 Performance Analysis of Various Mechanisms for Inter-process Communication에 관한 논문을 읽었습니다. 나는 파이프가 더 좋을 수도 있음을 나타내는 상반되는 결과 인 elsewhere을 보아왔다.

소량의 데이터를 보낼 때 간단히하기 위해 명명 된 파이프 (FIFO)를 선호합니다. 이를 위해서는 양방향 통신을 위해 한 쌍의 명명 된 파이프가 필요합니다. Unix 도메인 소켓은 설정 (소켓 생성, 초기화 및 연결)에 약간의 오버 헤드가 필요하지만 더 유연하며 더 나은 성능 (더 높은 처리량)을 제공 할 수 있습니다.

특정 애플리케이션/환경에 적합한 벤치 마크를 실행하여 가장 적합한 방법을 결정해야 할 수 있습니다. 제공된 설명에서 Unix 도메인 소켓이 가장 적합 할 것 같습니다.

Beej's Guide to Unix IPC는 리눅스/유닉스 IPC 시작하기에 적합합니다.

출처

2010-02-17 15:08:59 jschmier

성능이 실제로 문제가되는 경우 공유 메모리를 사용할 수 있지만 다른 방법보다 훨씬 복잡합니다. 데이터가 준비되었음을 알리는 신호 메커니즘 (세마포어 등)은 물론 잠금을 방지해야합니다 구조가 수정되는 동안 구조에 대한 동시 액세스

많은 경우 데이터를 메모리에 복사하지 않고 전송할 수 있기 때문에 경우에 따라 성능이 크게 향상됩니다.

아마도 공유 메모리를 통해 고급 기본 요소를 제공하는 사용 가능한 라이브러리가있을 수 있습니다.

공유 메모리는 일반적으로 MAP_SHARED를 사용하여 동일한 파일을 mmaping하여 얻을 수 있습니다 (영구 유지하지 않으려면 tmpfs에있을 수 있음). 많은 애플 리케이션도 System V 공유 메모리를 사용합니다 (역사적인 이유로 어리석은 IMHO, 똑같은 인터페이스에 대한 인터페이스가 훨씬 약합니다)

출처

2010-02-18 08:08:05 MarkR

아무도 dbus에 대해 언급하지 못했습니다. 성능이 중요한 제어 임베디드 환경에서 - - 당신은 공유 메모리를 이길 수 없습니다 응용 프로그램이 구조적으로 간단 경우

http://en.wikipedia.org/wiki/D-Bus

http://www.freedesktop.org/wiki/Software/dbus

는 경우, 맨 위에 조금 될 수 있습니다.

출처

2010-02-18 08:32:40 Dipstick

Dbus는 임베디드 환경에서 성능 문제가 있습니다. dbus를 통해 메시지를 만들어서 커널로 보낸 다음 다시 dbus로 보내면 많은 컨텍스트 스위칭이 생성됩니다. AF_BUS라는 새로운 소켓 유형을 사용하여 이러한 컨텍스트 스위치를 줄이는 패치가 있지만 Red Hat은 어떤 이유로 패치를 적용하지 않았습니다. – jeremiah

이 많은 컨텍스트 스위치 설계는 dbus의 원래 목표 인 IPC 메커니즘이 아니라 서비스 발견 버스라는 것을 나타냅니다. – jeremiah

@jeremiah : 임베디드 환경의 _performance 문제에 관한 모든 정보 _? 나는 프로파일 링과 온라인 조사를 해봤지만 심각한 문제는 보지 못했다. [여기]를 참조하십시오 (http://stackoverflow.com/questions/25085727/what-dbus-performance-issue-could-prevent-it-from-embedded-system) – minghua

이 글을 쓰는 시점 (2014 년 11 월) Kdbus와 Binder는 리눅스 커널의 준비 분기를 떠났습니다. 이 시점에서 어느 쪽이든 만들 것이라는 보장은 없지만, 그 전망은 양쪽 모두에 대해 어느 정도 긍정적입니다. Binder는 Android의 경량 IPC 메커니즘으로 Kdbus는 커널의 dbus와 유사한 IPC 메커니즘으로 컨텍스트 전환을 줄여 메시징 속도를 대폭 향상시킵니다.

강력하고 클러스터링 및 다중 노드 설정에 유용한 "투명 프로세스 간 통신"또는 TIPC가 있습니다. 신호, 익명 파이프, 명명 된 파이프 나 FIFO를, 시스템 V 메시지 큐, POSIX 메시지 큐, 시스템 V 공유 메모리, POSIX 공유 메모리, 시스템 V 세마포어 : http://tipc.sourceforge.net/

출처

2014-08-19 11:08:14 jeremiah

사용할 Linux IPC 기술은 무엇입니까?

답변

관련 문제