Enterprisebfiber_1900
Boost.Fiber Rationale
Rationale - 이론적 해석(접근 방식의 근거 또는 논리)
📦 preprocessor defines - 전처리기 정의
Table 1.6. preopcessor defines
| BOOST_FIBERS_NO_ATOMICS | no std::atomic<> used, inter-thread synchronization disabled |
| BOOST_FIBERS_SPINLOCK_STD_MUTEX | use std::mutex as spinlock instead of default XCHG-sinlock with backoff |
| BOOST_FIBERS_SPIN_BACKOFF | limit determines when to used std::this_thread::yield() instead of mnemonic pause/yield during busy wait (apllies on to XCHG-spinlock) |
| BOOST_FIBERS_SINGLE_CORE | allways call std::this_thread::yield() without backoff during busy wait (apllies on to XCHG-spinlock) |
📦 distinction between coroutines and fibers - 코루틴과 파이버의 차이점
파이버 라이브러리는 스케줄러와 동기화 메커니즘을 추가하여 코루틴(coroutine) 라이브러리를 확장합니다.
• a coroutine yields
• a fiber blocks
코루틴이 양보하면 제어권을 호출자(또는 대칭 코루틴의 경우 지정된 다른 코루틴)에게 직접 전달합니다.
파이버가 차단되면 파이버 스케줄러에 암시적으로 제어가 전달됩니다.
코루틴에는 스케줄러가 필요하지 않기 때문에 스케줄러가 없습니다.[12].
[12] 'N4024: Distinguishing coroutines and fibers' 코루틴과 파이버 구별
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf
📦 what about transactional memory - 트랜잭션 메모리는 어때요?
GCC는 버전 4.7부터 트랜잭션 메모리를 지원합니다.
불행하게도 테스트에 따르면 트랜잭션 메모리는 원자(atomics)를 사용하는 스핀록보다 느립니다(약 4배).
트랜잭션 메모리가 개선되면(하이브리드 TM 지원) 스핀록이 임계 섹션을 둘러싸는 __transaction_atomic{} 문으로 대체됩니다.
📦 synchronization between fibers running in different threads
다른 스레드에서 실행되는 파이버 간 동기화
Boost.Thread의 동기화 클래스는 전체(entire) 스레드를 차단합니다.
이와 대조적으로 Boost.Fiber의 동기화 클래스는 특정 파이버만 차단하므로 스케줄러는 그 동안 스레드가 계속해서 다른 파이버를 실행하는 바쁜 상태를 유지할 수 있습니다.
Boost.Fiber의 동기화 클래스는 스레드로부터 안전하도록 설계되었습니다.
즉, 동일한 스레드에서 실행되는 파이버뿐만 아니라 다른 스레드에서 실행되는 파이버도 동기화할 수 있습니다.
(그러나 크로스 스레드(cross-thread) 파이버 동기화 지원을 비활성화하는 빌드 옵션이 있습니다. 이 설명을 참조하십시오.)
https://www.boost.org/doc/libs/1_85_0/libs/fiber/doc/html/fiber/overview.html#cross_thread_sync
📦 spurious wakeup - 가짜 깨우기
'std::condition_variable'을 사용할 때 가짜 깨우기가 발생할 수 있습니다.
조건 변수는 신호를 받은 것으로 보이지만 대기된 조건은 여전히 거짓일 수 있습니다.
가짜 깨우기는 반복적으로 발생할 수 있으며 std::condition_variable 깨우기를 완전히 예측 가능하게 만들면 모든 std::condition_variable 작업이 느려지는 일부 다중 프로세서 시스템에서 발생합니다.[13]
'condition_variable'은 가짜 깨우기 대상이 아닙니다.
그럼에도 불구하고 wait() 루프에서 비즈니스 논리 조건을 테스트하는 것이 현명합니다.
또는 이와 동등하게 wait( lock, predicate ) 오버로드 중 하나를 사용하는 것이 좋습니다.
See also No Spurious Wakeups.
https://www.boost.org/doc/libs/1_85_0/libs/fiber/doc/html/fiber/synchronization/conditions.html#condition_variable_spurious_wakeups
[13] David R. Butenhof “Programming with POSIX Threads” - POSIX 스레드를 사용한 프로그래밍
📦 migrating fibers between threads - 스레드 사이의 파이버 이동
스레드 간 파이버 마이그레이션 지원이 통합되었습니다.
사용자 정의 스케줄러는 소스 스레드의 파이버 컨텍스트에서 context::detach()를 호출하고 대상 스레드의 context::attach()를 호출하여 마이그레이션할 파이버 컨텍스트를 전달해야 합니다.
(사용자 정의 스케줄러에 대한 자세한 내용은 사용자 정의를 참조하세요.)
https://www.boost.org/doc/libs/1_85_0/libs/fiber/doc/html/fiber/custom.html#custom
예제 디렉터리 예제의 work_sharing 및 work_stealing이 청사진으로 사용될 수 있습니다.
See also Migrating fibers between threads.
https://www.boost.org/doc/libs/1_85_0/libs/fiber/doc/html/fiber/migration.html#migration
📦 support for Boost.Asio - Boost.Asio 지원
Boost.Asio의 'async-result'에 대한 지원은 공식 API의 일부가 아닙니다.
그러나 'boost::asio::io_service'와 통합하려면 다른 메인 루프와 스레드 공유를 참조하세요.
https://www.boost.org/doc/libs/1_85_0/libs/fiber/doc/html/fiber/integration.html#integration
임의의 Asio 비동기 I/O 작업과 원활하게 인터페이스하려면 Boost.Asio가 있습니다.
https://www.boost.org/doc/libs/1_85_0/libs/fiber/doc/html/fiber/callbacks/then_there_s____boost_asio__.html#callbacks_asio
📦 tested compilers - 테스트된 컴파일러
라이브러리는 c++11 모드에서 GCC-5.1.1, Clang-3.6.0 및 MSVC-14.0으로 테스트되었습니다.
📦 supported architectures - 지원되는 아키텍처
Boost.Fiber는 Boost.Context에 의존합니다.
지원되는 아키텍처 목록은 여기에서 찾을 수 있습니다.
Boost.Context -> https://www.boost.org/doc/libs/release/libs/context/index.html
지원되는 아키텍처 목록 -> https://www.boost.org/doc/libs/release/libs/context/doc/html/context/architectures.html
