C++ 공부 해보려고 윈도우에서 소켓을 구현했는데 IO Event(IOCP, epoll, kqueue 등) 라던지, 소켓 내부 구현체가 리눅스와 달라서 직접 리눅스를 설치하고 개발을 해보려고 합니다! 후회중 😭 리눅스는 Arch linux 를 설치했고 데스크탑 환경은 KDE Plasma 를 선택했습니다. vim 기본 설정 처음 vim 을 설치하고 실행하면 정말 아무것도 없습니다. 까만 화면에 커서 하나만 있습니다. 농담이 아닙니다? 기본적으로 파일 인코딩, 라인 넘버, 탭 사이즈 등 기본적인 설정을 먼저 해줄겁니다. vim ~/.vimrc 를 입력하고 기호에 맞게 설정을 추가하세요!...
예전에 소켓을 만들 때 비동기 처리(?)를 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 의존성 주입은 프로그램 디자인이 결합도를 느슨하게 되도록 하고 의존관계 역전 원칙과 단일 책임 원칙을 따르도록 클라이언트의 생성에 대한 의존성을 클라이언트의 행위로부터 분리하는 것이다....