티스토리 뷰
Reactor 패턴
- 어떠한 이벤트가 발생하면, 이곳으로 알려달라는 방식.
- 윈도우 메시지 핸들러처럼, 특정 이벤트가 발생한다면 통지 받겠다는 방식.
Proactor 패턴
- 특정 작업을 시키고, 그 작업이 완료되면 알려달라는 방식.
- IOCP에서 Completion Port가 이 방식을 취하고 있다.
얼추 비슷한데, 구현에서 차이점이 명확해진다.
Proactor는 작업을 시키면서 콜백함수를 직접 넘김으로써 구현되고, Reactor는 디스패쳐를 구현하는 구조가 일반적.
Reactor 패턴 사용시에는 디스패쳐를 통함으로써 스팟 포인트가 발생하게 되는 단점이 있다고 보면된다.
이에 비해 Proactor는 명령을 내린 작업에 대해서만 통지를 받게 된다.
IOCP의 예를 들면, 내가 물려놓은 소켓에 Recv 이벤트가 발생했다고 해도, WSARecv를 걸지 않으면, 해당 이벤트가 발생했는지 여부에 대해 통지를 받지 않음을 의미한다.
이는 이벤트 폭발로 인한 부하 발생이나, 스팟 포인트를 감소 시킬 수 있는 테크니컬한 멀티 스레드 프로그래밍이 가능하게 하려면 Reactor 패턴보다는 Proactor 패턴이 유리하다는 것을 의미힌다.
Reactor 패턴은 디스패쳐를 거치기 때문에, 직렬화에 유리하긴 하나 이 디스패쳐가 스팟 포인트가 되는 것이 일반적이란 단점이 있다. (물론 그렇지 않게 구현 할 수 도 있으나, 그렇게 멀티스레드 로직을 수행하기엔 예외 상황이 지나치게 커질 위험이 있다.)
stateless 하게 구현하기 위해선 proactor 기반의 처리 구조로 구현하는 것이 좀 더 유리하다고 볼 수 있다. (stateless하게 만들 수 있다면, reactor패턴을 쓴다고 해도 스팟 포인트를 줄일 수 있긴 하다.)
'Software Engineering > Design Pattern' 카테고리의 다른 글
Design Pattern Quick Reference (0) | 2011.02.10 |
---|---|
데코레이터 패턴 (Decorator) (2) | 2008.02.09 |
커맨드 패턴 (Command) (0) | 2008.02.09 |
플라이웨이트 패턴 (Fly Weight) (0) | 2008.02.09 |
프록시 패턴 (Proxy) (0) | 2008.02.09 |
- Total
- Today
- Yesterday
- c언어
- 바로가기 프로그램
- CppSQLite
- 게임데브포에버
- EzShortcut
- 리버스 엔지니어링
- svn
- TDD
- 루비
- 루비 온 레일즈
- 디자인 패턴
- Ruby on Rails
- 멀티스레드
- 게임개발포에버
- MS-SQL
- SDL
- 엘키
- ftp
- 디버깅
- 임백준
- Rails
- perfmon
- RoR
- 좋은 프로그래머
- TraceRoute
- EasyExec
- NDC2013
- SQLite Spy
- 조엘 온 소프트웨어
- ruby
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |