비동기 프로그래밍은 다른 프로그래밍 트릭보다 훨씬 더 많은 철학입니다. 마지막 질문 은 주로 프로그래밍 측면에 대한 답변 을 얻었고 내 대답 은 주로 이론적 인 것으로 인해 분리 된 외로움이되었지만, 나는 단지 당신에게 동일한 참조에 대한 설명이 아니라 설명에 대한 새로운 관점을 제공하려고 노력하고 있습니다.
이것은 비동기 프로그래밍의 이유와 방법에 대한 몇 가지 기본 사항에 관한 것입니다.
빵집 가게에 가서 (케이크가 주문 후에 준비된다고 가정)-두 가지 선택이 있습니다 . 케이크가 준비 될 때 까지 기다리 거나 주문을하고 집으로 돌아가 집으로 데리러 오십시오. 나중에 준비되면. 첫 번째 (대기)는 동기식 이고 나중에는 비동기식 입니다. 말할 필요도없이이 예제는 동기식보다 비동기식 메소드를 사용해야하는 이유를 잘 보여줍니다.
이벤트 기반 프로그래밍은 비동기 시스템을 구축 할 수있는 방법 중 하나 일뿐 아니라 유용한 디자인 패턴 일뿐 아니라 아키텍처 패턴입니다. 이 이론이 실제로 유용한 방식으로 사용되는 사례를 나열하고 있습니다.
비동기 시스템의 첫 번째 예 중 하나는 Unix 시스템 IO입니다. 우리가 알고 있지만 read(), write()심지어 select()호출 블록에게 프로그램의 흐름을하지만, OS 안에, 그들은 비동기, 즉 커널은 일반적으로 같은 시간 CPU는 무료입니다 때까지 블록 장치 (일명 하드 디스크), 필 버퍼에 시간이 걸릴 것이라는 점을 알고있다 해당 스레드에서 스레드가 (준비되지 않은) 파킹됩니다. Moris Bach "Unix 운영 체제 디자인" 참조
가장 일반적인 또 다른 예는 대부분의 UI 프레임 워크입니다. 여기서 모든 사용자 클릭은 먼저 각 애플리케이션 을 콜백 하는 컨트롤러를 통해 발송됩니다 . 중요한 것은 이러한 콜백은 콜백을 대기하지 않아야 시스템이 멈추는 것입니다. UI 컨트롤러에서 백엔드로의 콜백은 처리량이 많은 경우 일반적으로 비동기입니다.
비동기 프로그래밍의 또 다른 좋은 예 (순수한 디자인 패턴)는 Active Object입니다. 활성 객체는 많은 요청을 대기열에 보관하고 하나씩 실행할 수 있도록 자체 전용 스레드 를 가진 객체입니다 . 이 백서 : 활성 개체를 참조하십시오 . 이 패턴은 엔터프라이즈 소프트웨어에서 모바일 프레임 워크에 많이 사용됩니다. 널리 사용되는 플랫폼 Java / EJB 및 .NET은 로컬 또는 원격 비동기 메소드 호출 을 허용하므로 기본 오브젝트는 기본적으로 활성 오브젝트가 될 수 있습니다. Aapo Haapanen의 Symbian OS에서 활성 개체 는 Symbian : Active 개체에서 다시 나타납니다 ( Symbian의 활성 개체 참조 ). 이것은 현재에도 존재합니다안드로이드 ).
같은 저자 Douglas C. Schmidt 는 Active 객체와는 별도로 Active 객체와 평행을 이루고 비동기 패턴 인 다른 많은 작품을 제작했습니다. 이 이벤트 처리 패턴을 참조하십시오 . 그의 책 Pattern-Oriented Software Architecture : 동시 및 네트워크 오브젝트의 패턴-V2 에서 전체 계정을 사용할 수 있습니다.
실제로 작업을 수행하기 위해 백그라운드에서 작업 하는 동안 지정된 객체가 API를 반환해야하는 경우 일반적인 방법은이를 달성하기 위해 다중 스레드 시스템을 사용하는 것입니다. 스레드 시스템은 C (posix), C ++ ( boost )에서 Java, C # 등 어디에나 존재 합니다. 활성 객체는 본질적으로 이것을 숨길 수있는 추상화 일뿐입니다. 활성 스레드 구현이 기본 스레드보다 선호되는 이유를 확인하십시오 . 또 다른 좋은 읽을 거리 .
그러나이 개념은 애플리케이션 내부의 스레드 나 객체를 넘어 비 동기화됩니다. 가장 좋은 사용법 중 하나는 두 응용 프로그램이 반드시 조정을 위해 서로를 기다릴 필요가없는 분산 시스템입니다. 오래된 것 (또는 그렇지 않은 것), RPC 는 동기식입니다. 물론 다른 비동기 RPC 도 있습니다. 그러나 Message Oriented Middleware 와 같은 현대적인 대안 은 좋은 이유로 비동기식입니다.
마지막으로 가장 흥미로운 것은 비동기 통신 모델의 이점을 얻을 수 있는 에이전트 프로그래밍 입니다 .
비동기 프로그래밍은 섹시 해 보이지만 다음과 같은 자체적 인 복잡성을 만듭니다.
- 반환 값 전달을위한 프레임 워크
- 통신의 추가 오버 헤드
- 구문 동기화에 대한 추가 요구
- 일이 잘못되면 교착 상태, 경주 등의 가능성.
... 등등.
항상 진정한 이유로 만 사용해야합니다.
그렇다면 언제 비동기 모델을 사용해야합니까? 백그라운드 스레드를 배치하고 호출자가 비동기로 전환하도록 허용해야하는 시점은 다음과 같습니다 (완전하지는 않지만).
시스템이 엄격한 심각한 리소스 대화를 적용하려는 경우 : 예를 들어 절대 고정 수의 스레드를 유지하려고합니다. 비동기 패턴은 시스템이 큐를 구현하도록합니다.
발신자가 "다른 유용한 작업 " 을 수행해야 할 때는 실제로 정품입니다. 따라서 여러 스레드에서 차단을 해제하더라도 다른 스레드는 유용한 기능을 수행하지 않으며 결과 폴링을 중단합니다. 이것은 실제로 기본 동기 모델보다 CPU를 더 많이 소비 할 수 있습니다.
분산 시스템에서 높은 수준의 안정성이 필요한 경우 ( 메시지 지향 미들웨어 참조 ).