요약
- 다중 프로세스
- 장점
- 프로그래밍이 간단하여 매우 이해하기 쉬움
- 개별 프로세스 주소 공간이 격리되어 있어 다른 하나의 프로세스에 문제가 발생하여 강제 종료되더라도 다른 프로세스에 영향을 미치지 않음.
- 다중 코어 리소스를 최대한 활용할 수 있음.
- 단점
- 프로세스 공간 격리로 인해 서로 통신이 필요할 때 난이도가 올라감. -> 프로세스 통신 작동 방식을 사용해야 함.
- 프로세스 생성시 부담이 큼.
- 다중 스레드
- 스레드는 프로세스 주소 공간을 공유함.
- 스레드 간 통신을 위해 별도 통신 작동 방식을 사용할 필요 없음.
- 서로 같은 주소 공간을 공유하기에 하나의 스레드가 문제가 발생하여 강제 종료되면 같은 프로세스를 공유하는 모든 스레드와 프로세스가 한꺼번에 강제 종료됨.
- 여러 스레드가 공유 리소스를 동시에 읽고 쓸 수 있는 부작용이 있음. -> 상호 배제 작동 방식을 이해해야 함.
- 교착 상태처럼 일련의 문제를 일으킬 수 있음.
- 사용 규모가 크지 않은 경우 다중 스레드로 충분히 처리 가능함.
- 하지만 동시 요청 수가 매우 많을 때는 다중 스레드만으로 감당이 어려움.
- 이벤트 순환과 이벤트 구동
- 병행 프로그래밍으로 "이벤트 기반 동시성"을 이용한 "이벤트 기반 프로그래밍"을 이용할 수도 있음.
- 이벤트가 도착하면 이벤트 유형을 확인한 후, 그에 대응하는 이벤트 처리 함수 핸들러가 작동함.
- 이벤트 소스와 입출력 다중화
- 리눅스와 유닉스 세계에서 모든 것이 "파일"로 취급 됨.
- 프로그램은 모두 팡리 서술자를 사용하여 입출력 작업을 실행함 -> 소켓도 예외가 아님.
- 동시에 파일 서술자 여러개를 처리하려면 서술자를 감시하다가 데이터가 들어오면 알려달라고 해야 함.
- 이 동작을 '입출력 다중화' 라고 하며 리눅스에서 가장 유명한 epoll 이 됨.
- 이벤트 처리 핸들러 함수는 반드시 이벤트 순환과 같은 스레드에서 실행되야 하는가?
- 핸들러 작업이 짧으면 핸들러와 순환을 동일한 스레드에서 실행하면 됨.
- 근데 핸들러가 CPU 시간을 많이 잡아먹는다면CPU 다중 코어를 확룔하기 위한 다중 스레드를 사용 해야 함.
- 여기서 이벤트 순환이 워커 스레드가 되고, 핸들러 함수가 이벤트 루프 스레드로서 각각 병행 실행하기 됨.
- 이러한 설계 방법을 "반응자 패턴" 이라고 함.
댓글