예전에 소켓을 만들 때 비동기 처리(?)를 select() 함수를 이용해서 처리했었는데, 이 함수를 사용한 서버는 많은 동시 접속자 및 고성능에는 적합하지 않다고 해서 다른 방법을 찾아보기로 했습니다. Blocking 이 있으면 모두 동기식입니다. 왜 적합하지 않을까❓ FD_SET 비효율적인 사용 select() 호출 때마다 파일 디스크립터 배열을 다시 세팅해서 전달 polling 방식 select() 함수 내부에서는 파일 디스크립터를 순회하며 감지함 접속한 클라이언트가 많아질수록 성능이 떨어짐 파일 디스크립터 최대 개수 허용하는 최대 개수가 1024개 따라서 고성능 서버에서는 사용되지 않는다....
이전 글에서는 메모리풀의 개념과 싱글 스레드에서 사용할 메모리풀을 구현해 보았습니다. 이번 글은 thread-safe 한 메모리풀을 구현해 볼겁니다! 😄 ✅ mutex 와 lock-free 로 만들 수 있는데 이번 글은 lock-free 를 이용해서 만들겠습니다. 🚀 Lock-free 메모리풀 ✨ 공유 자원 _header 및 CAS 문제 해결을 위해 Tag 추가 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 #ifndef __LF_MEMORY_POOL_H__ #define __LF_MEMORY_POOL_H__ #include<algorithm> #include<cstring> #include<atomic> template<typename T, size_t capacity = 1024> class LFMemoryPool { struct LinkedList { LinkedList *next; }; using TaggedLinkedList = std::pair<LinkedList *, uint64_t>; static constexpr size_t alignment = std::max(alignof(T), alignof(LinkedList)); static constexpr size_t blockSize = std::max(sizeof(T), sizeof(LinkedList)); public: LFMemoryPool() : _chunk{0,} , _header({nullptr, 0}) { TaggedLinkedList header = _header....
프로그램이 런타임 중에 동적으로 메모리를 할당하려면 new/delete 키워드를 사용하여 운영체제한테 메모리를 요구합니다. 이 때 시스템 콜을 시작으로(커널 모드 진입) 전역 힙에서 요청한 크기의 블록을 찾고 Free list 를 관리하며 필요한 경우 메모리 페이지 테이블 업데이트 등의 작업을 수행하고 여러 스레드가 동시에 힙에 접근하는 것을 막기 위해 동기화 작업도 진행됩니다. 현대의 응용 프로그래밍은 이런 내부적인 상황까지 고려하여 설계하지 않겠지만, 최적화 관점에서 볼 때 동적으로 생성하는 것(메모리, 스레드 등등)을 최소화하면 좋다는 것입니다! 😄...
프로그램이나 앱이 한번 가동되면 종료될 때까지 한 개의 인스턴스만을 가져야 하는 경우가 있습니다. 예를 들면 소켓, I/O 처리, 옵션 설정 등이 있을 겁니다. 지금까지 싱글톤 패턴을 이용해 어디서든 instance를 가져와 사용했었는데, 아주 큰 단점이 하나 있습니다. 사용하는 순간 종속되어 단위 테스트와 다른 프로젝트에 재활용할 수 없다는 것이죠. 😨 그래서 최대한 싱글톤 사용을 지양하고자 다른 방법을 찾게 되었습니다. 바로 의존성 주입(DI)죠. 🔍 의존성 주입 (DI, Dependency Injection) 💡 Quotation 의존성 주입은 프로그램 디자인이 결합도를 느슨하게 되도록 하고 의존관계 역전 원칙과 단일 책임 원칙을 따르도록 클라이언트의 생성에 대한 의존성을 클라이언트의 행위로부터 분리하는 것이다....
지난번에 만들었던 스레드풀은 mutex를 이용하여 하나의 작업 큐(공유자원)을 lock-unlock 을 이용하여 각 스레드가 작업을 가져갔습니다. 스레드가 많고 작업 시간이 짧을 수록 더 많은 경쟁을 할 것인데 이로 인해 작업을 처리하는 비용보다 작업을 빼오는 오버헤드가 더 클 것 같습니다. 😨 💡 항상 Lock-free가 빠른 것은 아님! 따라서 벤치마킹 후 성능이 좋은 쪽을 선택해야 합니다. 🚀 Lock-free 작업 큐 구현 기존 스레드풀에서 thread-unsafety 였던 큐를 Lock-free 큐로 변경을 하려고 합니다. 그러기 위해 큐를 직접 구현해야 하는데 큐의 조건은 다음과 같습니다....