cplusplus: 실전적 클래스 설계와 구현

생각보다 현업에서 많이 사소하게 사용하는 게 bool flag입니다. 단순한 상태 저장용으로 쓰기 시작하지만 복잡한 루프나 멀티스레드 환경을 만나면 간단했던 플래그가 만만치 않게 됩니다. 또 상태 하나를 체크하기 위해 이전값과 같은지 수동으로 비교하고 값을 업데이트해주어야 합니다. 일반적인 Flag 사용bool is_active = false; // 이전 상태 저장용void on_receive_signal(bool status){ // 켜지는 시점 감지: "현재는 true인데, 이전엔 false였나?" if (status == true && is_active == false) { is_active = true; // 상태 수동 갱신 std::cout 생각보다 현업에서 사소하게 사용되는..

어플리케이션에서 흔히 볼 수 있는 코드 중 하나가 마스터 정보를 메모리에 두고 다수의 쓰레드가 검색하는 것입니다. 이런 Read-Only 데이터셋은 굳이 Lock을 만들 필요가 없습니다. 하지만 이 마스터 정보가 간헐적으로 업데이트된다면 하는 수 없이 Lock을 사용해야 하는데요,간헐적으로 일어나는 업데이트 때문에 다수의 쓰레드도 데이터셋에 접근시마다 Lock을 사용할 수밖에 없습니다. 이렇게 되면 싱글쓰레드에서 검색하는 게 오히려 더 빠릅니다. C++ std::mutex보다 빠른 RCU(Lock-free) 라이브러리: cppurcuC++ Lock-free library faster than std::mutex: cppurcu 읽기 작업이 많은 프로세스멀티스레드 환경에서 특정 자료는 거의 읽기가 대부분..

들어가며 모던 C++을 사용하지 않은 코드에서는 std::string이나 std::array보다는 문자 기반의 배열을 자주 사용합니다. 이러한 방식은 코딩 실수가 발생하기 쉬우며, 그로 인해 의도치 않은 동작이나 비정상적인 종료로 이어질 수 있습니다. 특히 구조체에 이런 배열을 십수 개 이상 선언하는 관습에서는, 배열 복사 과정에서 발생하는 오류를 찾기가 쉽지 않습니다. 테스트를 진행하더라도 오류가 발생한 지점에서 즉시 종료되지 않는 경우가 많기 때문에, 문제를 더욱 찾기 어렵게 만듭니다. 이러한 배열 복사는 오늘날 실무에서도 여전히 자주 사용되고 있습니다. 때문에 모던 C++을 잘 모르는 많은 개발자들은 아직도 배열을 하나하나 확인하는 고통을 받고 있습니다. :( 여기서는 모던 C++을 이용하여 자동..

C의 getopt는 프로그램에서 인자 호출 시 많이 사용합니다. 보통은 아래와 같이 사용하는데요, 이렇게 하면 인자 처리하는데 많은 코드 양과 다른 부분들이 뒤섞이면서 좀 복잡해집니다. 고전 C 스타일#include #include #include #include #include int main(int argc, char *argv[]) { int opt; int a_flag = 0, b_flag = 0, c_flag = 0; int a_value = 0; int b_value = 3; // 기본값 char c_value[256] = {0}; // 명령줄 인수 파싱 while ((opt = getopt(argc, argv, "a:b:c:v")) != -1) { switch ..

C++ 강력한 동시성 제어(1) - BlockingQueue 이해C++ 강력한 동시성 제어(2) - BlockingQueue 구현C++ 강력한 동시성 제어(3) - BlockingQueue을 이용한 Logger 이 글에서는 이전 포스팅 "C++ 강력한 동시성 제어(1) - BlockingQueue" 에서 구현해야 할 BlockingQueue를 std::deque가 아닌 std::vector기반으로 구현합니다. 이 구현은 boost::lockfree::queue보다 빠르며 표준 라이브러리를 이용한 구현으로 안정성과 편의성(자유로운 데이터형식, 디버깅)이 높고 외부 의존성을 피할 수 있습니다. std::vector기반의 BlockingQueue 벤치마크는 "C++ Lockfree Queue 항상 좋은 선택일..

C++은 11 버전부터 Thread Local Storage를 지원하기 시작했습니다. 그 이전에는 Windows NT (__declspec(thread)) - 1994, POSIX threads (pthread_key_*) - 1995, GCC (__thread) - 2002에서 지원하기 시작했습니다. 이 오래된 Thread Local Storage(이하 TLS)는 그만큼 매우 유용한 기능이라 볼 수 있습니다. errno도 대표적인 TLS변수입니다. TLS의 장점은 각 개별 쓰레드가 필요한 리소스 경쟁을 피하면서도 성능과 사용성에 유리하게 적용할 수 있다는 점입니다. 같이보면 좋은 글C++ 멀티쓰레드: Read-Only 데이터셋의 업데이트와 락프리 접근C++ std::mutex보다 빠른 RCU(Lock..

std::condition_variable의 안전한 시그널링std::thread의 실전적 랩핑 - thread 클래스 구현 C++17로 진화하기: std::condition_variable 안전한 랩핑 C++17로 진화하기: std::condition_variable의 안전한 랩핑이전에 아래 내용을 C++11로 랩핑 하였는데요, std::condition_variable의 안전한 시그널링앞서 소개한 위 코드를 C++17로 다시 랩핑 하려 합니다. 특히 std::condition_variable에서의 C++11의 복잡했던 템플릿식cplusplus.tistory.com [[아래 글은 C++11 기준]] 쓰레드 간 동기화와 시그널링은 멀티쓰레드 프로그래밍에서 가장 기본적이면서도 까다로운 문제 중 하나입니다..

RAII(Resource Acquisition Is Initialization)는 현대 언어에 와서는 없어서는 안 될 필수 개념으로 자리 잡았습니다. 그리고 현대 언어들에게 많은 영향을 끼쳤습니다. 하지만 이를 적극 활용하여 개발하는 C++개발자는 게임 이외의 산업에서는 드문 편입니다. 한국은 젊은 C++개발자들이 없어서 일까요? 아니면 C개발자들이 마지못해 JAVA나 C++시장으로 밀려들어와서 일까요. C99 부터는 C++과 호환되지 않습니다. C는 C23표준에 와서야 자동해제를 지원하기 시작했습니다.) C개발자들이 C++ 생태계에 참여하는 것은 매우 환영할 만한 일입니다. 하지만 이 과정에서 C++의 현대적 특성이 이해되지 않고, 단순히 'C의 확장' 정도로 취급되는 현실은 비판적으로 바라볼 필요가 ..

동시성 프로그래밍에서 락-프리(queue) 데이터 구조는 매력적으로 보일 수 있습니다. 블로킹이 없는 비블로킹 설계 덕분에 높은 성능과 낮은 지연 시간을 기대할 수 있기 때문입니다. 그러나 락-프리 큐가 항상 최선일지는 정말 고려할 점이 생각보다 많습니다.장점 - 블로킹 없는 높은 성능, 지연시간 감소, 교착상태 없음단점 - 구현시 복잡도(CAS경합, 메모리 관리, ABA문제), 대기 시 CPU소모량, 제약조건들 또는 외부 라이브러리 의존성.락프리 알고리즘을 구현하려면 하드웨어부터 운영체제, 컴파일러, 그리고 애플리케이션 레벨까지 모든 계층에서 세심한 주의가 필요합니다. C++ Core Guidelines에서는 락프리 프로그래밍을 정말 필요치 않으면 사용하지 말라고 권고하고 있으며 이런 구현상의 난이도 ..