2012-04-19 4 views
5

내가 아는 활성 객체 디자인 패턴은 객체와의 (개인/전용) 스레드 수명을 묶어 독립적 인 데이터에서 작동하도록 만드는 것입니다. 필자가 읽은 문서 중 일부에서, 이런 종류의 패러다임의 진화는 원시 스레드 관리가 어려워지고 공유 리소스를 위해 두 번째로 더 많은 스레드가 뮤텍스와 잠금을 사용하여 확장되지 않는 두 가지 이유 때문에 발생했습니다. 제가 첫 번째 이유에 동의하는 동안, 저는 두 번째 것을 완전히 이해하지 못합니다. 객체를 활성화시키는 것은 객체를 독립적으로 만들지 만 잠금/뮤텍스에 대한 경합 같은 문제는 여전히 남아 있습니다 (우리가 여전히 공유 큐/버퍼를 가지고 있기 때문에) 객체는 공유 책임을 메시지 큐에 위임했습니다. 이 디자인 패턴의 유일한 장점은 공유 객체에서 긴 asynch 작업을 수행해야하는 경우입니다. 이제는 공유 대기열에 메시지를 전달할 때 스레드가 더 이상 뮤텍스/잠금 장치는 여전히 메시지/작업 게시를 방해하고 경쟁 할 것입니다. 이 경우를 제외하고 누군가가 이런 종류의 디자인 패턴이 다른 이점을 가질 수있는 더 많은 시나리오를 말할 수 있습니다.활성 개체를 사용 하시겠습니까?

내가 가진 두 번째 질문은 액티브 오브젝트, 반응기 및 프록터 디자인 패턴의 개념적 차이가 무엇인지 (방금 디자인 패턴을 파고 들기 시작한 것)입니다. 어떤 디자인 패턴이 더 효율적이고 귀하의 요구 사항에 더 적합한 지 어떻게 결정합니까? 세 가지 디자인 패턴이 어떻게 작동하는지, 다른 시나리오에서 비교 우위와 단점을 보여주는 사례를 보여줄 수 있다면 정말 좋을 것입니다.

활성 스레드 (공유 스레드 안전 버퍼 사용) 및 부스트 :: asio (Proactor)를 사용하여 유사한 종류의 비동기 작업을 수행 할 때 혼란 스럽습니다. 어떤 것이 있는지 알고 싶습니다. 문제에 접근 할 때 다른 패턴의 적용 가능성에 대한 더 많은 통찰력.

답변

4

ACE website에는 Active Object, ProactorReactor 디자인 패턴에 대한 아주 좋은 논문이 있습니다. 자신의 의도에 대한 간단한 요약 :

액티브 객체 디자인 패턴은 메소드 호출에서 메소드 실행 를 디커플링은 동시성을 향상하고 제어의 그것 자신의 스레드에있는 개체에 대한 동기화 된 액세스를 단순화. 별칭 : 동시 객체, 액터.

Proactor 패턴은 역 다중화 및 비동기 이벤트의 완료 에 의해 트리거되는 여러 이벤트 핸들러의 파견을 지원합니다. 이 패턴은 Boost.Asio에서 많이 사용됩니다.

반응기 디자인 패턴은 하나 이상의 클라이언트가 응용 프로그램에 동시에 배달 한 서비스 요청을 처리합니다. 응용 프로그램의 각 서비스 은 여러 가지 방법으로 구성 될 수 있으며 서비스 별 요청을 처리하는 별도의 이벤트 처리기 인 으로 표시됩니다. 일컬어 Dispatcher, Notifier.