Boost::asio – Overview – Core Concepts and Functionality – Thread and Boost.Asio

출처: http://www.dhsnest.com/2010/03/boostasio-overview-core-concepts-and-functionality-thread-and-boostasio/

---

스레드와 Boost.Asio

스레드 안정성

일반적으로, 동시에 다른 객체에 접근하면 안전하다고 하나 같은 객체를 사용하면 안전하지 않다고 합니다. 그러나 io_service와 같은 형태는 동시에 하나의 객체를 사용해도 강력한 안정성을 보장합니다.

스레드 풀

여러개의 스레드에서 Completion handler에서 호출되는 스레드 풀을 설정하기 위해 io_service::run()함수를 호출할 있습니다. 또한 이 방법은 io_service::post()함수와 함께 사용되어 스레드 풀 사이의 어떠한 연산 작업도 할 수 있습니다.

이는 하나의 io_service의 스레드 풀에 참여한 모든 스레드는 동등하다고 할 수 있습니다. 그리고 io_service가 임의로 작업을 분배할 수 있습니다.

내부 스레드

라이브러리의 구현에서 일부 플랫폼은 비동기를 에뮬레이트하기 위해 하나 혹은 다수의 내부 스레드를 생성할 수 있습니다. 가능한 이 스레드들은 절대 라이브러리 사용자들에게 보이지 않습니다. 특히 이 스레드들은 :

• 사용자의 코드에서 직접 호출 될 수 없습니다. 또한,


• 모든 신호를 블럭킹합니다.

Note

현재 구현된 라이브러리의 아래 함수들은 첫번째 규칙을 위반하고 있습니다:

- 모든 플랫폼의 ip::basic_resolver::async_resolve()

- 윈도우즈의 basic_socket::async_connect()

- 윈도우즈에서 stream-oriented 소켓에서 발생하는 비동기 읽기가 아닌 null_buffers() 함수와 관련된 모든 동작

이러한 방법은 다음과 같은 방법으로 보완되었습니다:

• Asynchronous completion handler는 현재 io_service::run() 함수를 호출한 스레드에 의해서만 호출될 수 있습니다.

따라서, Notification이 전달될 모든 스레드의 생성과 관리는 라이브러리 사용자의 책임입니다.

이러한 방법을 사용한 이유는 다음과 같습니다:

• 단일스레드에서만 io_service::run()을 호출하므로, 개발 과정에서 동기화와 관련된 복잡성을 피할 수 있습니다. 예를 들어, 라이브러리 사용자는 단일 스레드 기반의 확장 가능한 서버(사용자 관점에서)를 구현할 수 있습니다.

• 라이브러리 사용자는 스레드가 시작한 직후와 다른 코드가 실행되기 전에 초기화가 필요할 수 있습니다. 예를 들어, Microsoft의 COM사용자는 스레드에 COM이 호출되기 전에 CoInitializeEx를 호출해야 합니다

• 라이브러리 인터페이스가 스레드 생성과 관리에 관련된 인터페이스와 분리되었습니다. 그리고 스레드가 불가능한 플랫폼에서의 구현을 가능하게 합니다.