Linux 시스템은 공유 메모리에 대해 레거시 시스템 V API와 최신 POSIX API의 두 가지 별도 API를 제공합니다. 그러나 이러한 API는 단일 응용 프로그램에서 혼합해서는 안 됩니다. POSIX 접근 방식의 단점은 기능이 아직 개발 중이며 코드 이식성에 영향을 주는 설치된 커널 버전에 따라 달라지는 것입니다. 예를 들어 POSIX API는 기본적으로 공유 메모리를 메모리 매핑 된 파일로 구현합니다. POSIX에서 공유 메모리는 백업 파일 없이 구성할 수 있지만 이식성에 영향을 미칠 수 있습니다. 내 예는 메모리 액세스 (속도) 및 파일 저장소 (지 속성)의 이점을 결합 하는 백업 파일과 POSIX API를 사용 합니다. 세마포는 데이터의 일반적인 교환을 허용하지 않기 때문에 이 장에서 설명하는 다른 형태의 IPC와 다릅니다. 즉, 세마포를 사용하여 응용 프로그램 별 정보를 한 프로세스에서 다른 프로세스로 전송할 수 없습니다. 대신 세마포어는 공유 리소스에 대한 액세스를 동기화하는 데 사용됩니다. 즉, 세마포는 충돌할 수 있는 공유 액세스의 타이밍을 제어합니다. 세마포어는 메시지 큐 및 공유 메모리와 마찬가지로 POSIX 및 System V 인터페이스 사양을 모두 갖습니다.
세마포의 두 버전 간의 주요 차이점은 다음과 같습니다: 공유 잠금은 효율성을 촉진합니다. 한 프로세스가 파일을 읽고 내용을 변경하지 않는 경우 다른 프로세스가 동일한 작업을 수행하지 못하도록 할 이유가 없습니다. 그러나 쓰기에는 파일에 대한 단독 액세스가 분명히 요구됩니다. 두 순서 중 하나에서 세마포는 ProcA가 공유 메모리에 쓰기를 완료할 때까지 ProcB가 데이터를 읽을 수 없음을 보장합니다. 공유 파일 및 공유 메모리 예제에서는 프로세스가 공유 저장소, 한 경우의 파일 및 다른 경우의 메모리 세그먼트를 통해 프로세스와 통신하는 방법을 보여 준다. 두 방법 모두에 대한 API는 비교적 간단합니다. 이러한 접근 방식에는 공통적인 단점이 있습니까? 현대의 응용 프로그램은 실제로 대규모 데이터 스트림을 통해 스트리밍 데이터를 처리하는 경우가 많습니다. 공유 파일이나 공유 메모리 접근 방식은 대규모 데이터 스트림에 적합하지 않습니다. 한 유형 또는 다른 채널이 더 적합합니다.
따라서 2부에서는 C의 코드 예제와 함께 채널 및 메시지 큐를 다시 도입합니다. 다음 예제에서는 위에서 세마포예와 동일한 System V를 보여 주실 수 있습니다. 다른 시스템 V IPC 코드와 마찬가지로 먼저 세마포를 식별하기 위해 key_t가 필요합니다. 세마포를 만든 후 세마포의 식별자 sem및 인수(공용구조체 변수에 지정)와 함께 SETVAL 매개변수를 semctl()에 전달하여 초기화됩니다. 두 번째 매개 변수 semnum semctl()에 대 한 두 호출에서 0으로 설정 되지만 다른 이유로 합니다. 세마포의 값을 초기화하는 데 사용되는 첫 번째 semctl()에서 semnum은 집합에서 수정되는 세마포를 나타냅니다. 마지막 줄의 semctl()은 집합 자체를 삭제합니다. 단일 세마포가 아닌 집합에 영향을 주는 작업의 경우 semnum이 무시되고 일반적으로 0으로 설정됩니다. 부모(생산자)가 N자식(소비자) 스레드를 생성하고 전역 배열을 사용하여 이들 간에 데이터를 통신하는 샘플 응용 프로그램을 작성했습니다. 전역 배열은 순환 메모리이며 데이터가 배열에 기록될 때 보호됩니다.
이 첫 번째 코드 예제에서 IPC를 통해 공유되는 데이터는 셰익스피어의 연극 리처드 III의 두 줄입니다. 그러나 공유 파일의 내용은 볼륨감 있는 임의 바이트(예: 디지털화된 동영상)일 수 있으며, 이로 인해 파일 공유는 매우 유연한 IPC 메커니즘이 될 수 있습니다. 단점은 액세스가 읽기 또는 쓰기와 관련이 있는지 여부에 관계없이 파일 액세스가 상대적으로 느리다는 것입니다. 언제나 그렇듯이 프로그래밍에는 장단점이 있습니다.