기존 이솝 임베디드 포럼의 지식인 서비스가 게시판 형태로 변경되었습니다.
안녕하세요?
안드로이드 OpenBinder를 보고 있는데요,
기존 IPC 방식보다 오버헤드 면에서 개선이 됐다고 하는데 어떤 점 때문에 그런가요?
제가 잠시 분석해보기로는,
기존 IPC는 커널 내 Socket이나 Shared Memory를 사용하여 프로세스 간 데이터 통신을 했는데 안드로이드는 전용 Binder Driver를 사용하고 있다는 걸 알았습니다. 드라이버내에서 binder_mmap() 함수를 사용하여 전달하고자 하는 데이터 크기만큼만 버퍼를 할당하여 사용하던데, 이 방식이면 기존 보다 메모리 누수면에서는 좋지만 오버헤드와는 상관이 없어 보이더라고요.
오버헤드 관점에서 기존 IPC 보다 좋아진 key point를 알고 싶습니다.
(Context Manager 부분을 보고 있는데 이 부분에 key 가 있는거 같기도 하고.. )
Socket을 다루는 부분은 Filesystem과 연결되어 있고, System V IPC는 해당 id등을 관리하는 부분의 오버헤드가 나름 있고, mmap()을 쓴 부분이 기존의 IPC들과 많이 차이가 있다라고 생각이 듭니다.
mmap()의 경우는 가장 나중에 나온 system call의 형태인데, 원래의 UNIX 철학에는 맞지가 않는 system call입니다(kernel과 user space의 완벽한 분리라는).
하지만 데이터 전송에서는 가장 빠른 면을 보여주기 때문에, 잘만 사용한다면.......(이게 제일 중요한 부분일 듯), 가장 빠른 데이터 전송을 보여준다고 볼 수 있습니다.
Context Manager는 오버헤드라기 보다는 제가 보기에는 IPC의 중앙집중형 관리쪽에 가깝다고 볼 수 있을 듯 합니다.
결과적으로 제가 생각할 때의 Binder의 장점은
1. IPC 사용법의 중앙집중화 - 즉, process간만의 약속이 아닌, 전체 시스템 레벨로의 기능 확장2. mmap()을 이용한 데이터 전송의 효율화3. IPC 사용법의 복잡함을 class를 이용한 wrapper를 이용하여 되도록이면 쉽게 사용하고, 시스템 레벨에서 쉽게 사용할 수 있는 표준화된 방법의 제공
라고 보고 있습니다.
물론, OpenBinder의 가장 앞에 나오는 "왜 오픈 바인더를 사용하는가?"에 대한 부분을 제외한 내용입니다.(즉, System availability, Lobust application 등과 같은 부분을 제외한 부분의...)