system

JVM Compressed OOPs Compressed OOPs란 무엇인가? OOPs(Ordinary Object Pointers)는 JVM 내부에서 힙 객체의 참조 주소를 가리키는 포인터를 뜻합니다. 자바 코드에서 로 생성된 객체의 메모리 주소를 가리키는 내부 포인터입니다. Compressed OOPs는 이름에서 알 수 있듯 "압축된 포인터"로 이해할 수 있는데요. 32비트 시스템과 64비트 시스템을 중심으로 이에 대해 알아봅시다. 32비트 vs 64비트 32비트 시스템 - 32비트 주소 버스와 64비트 데이터 버스를 가지는 Pentium - 32비트 CPU는 주소 버스(Address Bus) 폭이 32비트입니다. (레지스터 폭과 주소 버스 폭이 다른 CPU 아키텍처도 존재하나 예외로 생각하겠습니다.) 즉, 한 번에 32개의 비트를 사용해 메모리의 주소를 지정할 수 있습니다. 2^32 = 4,294,967,296 byte = 4GB 이 말은 CPU가 직접 접근할 수 있는 물리적 메

TLS(Thread Local Storage) 쓰레드마다 갖고 있는 로컬 저장소 != 스택 - 동물원의 호랑이를 생각해보자 - 공통 영역에서 큼지막한 덩어리를 가져온 다음 필요한걸 꺼내쓰면 처음 가져올 때만 경합이 발생하고 큰 덩어리에서 고를 때는 경합이 필요 없다. TLS 예제 - 로 받는 난수 id가 아닌 쓰레드마다 직접 id를 할당하고 싶다면? 실행 결과 - 각 쓰레드 마다 자신의 id를 TLS에 저장했음을 확인할 수 있다. - 이를 응용해서 쓰레드별 Stack이나 Queue를 구현할 수도 있다. 이어지는 궁금증... - TLS는 스택영역과는 별개의 개념이라고 했다. - 그럼 각 쓰레드의 TLS 공간은 전역변수 데이터 영역에 저장되며 다른 쓰레드에 의해 침범될 수 있을까? 이에 관련한 문답을 링크 : Stack overflow 에서 찾았다.

CPU Pipeline 여기서는 Pipeline의 효율 최대화를 위한 코드 재배치에 대해 알아볼 것이며, Pipeline Hazard, RISC, CISC에 관한 내용은 생략합니다. 개요 - CPU가 연산 속도를 향상시키고 노는 시간을 최대한 줄이기 위해 CPU 파이프라인을 도입한다는 사실은 익숙하다. - CPU는 각 연산 모듈(ALU 등)간 연산 속도, Task당 분배해야하는 시간 등을 고려하여 속도를 최적화 시키기 위해 로직이 엉키지 않는 선에서 코드 재배치를 수행한다. - 일반적인 상황(싱글 쓰레드 = 중량 프로세스)에서는 이러한 코드 재배치가 논리 구조를 건드리지 않는 선에서 동작하기 때문에 문제를 일으키지 않지만, 멀티 쓰레드 환경에서는 이야기가 조금 다르다. - 쓰레드간 논리 구조가, CPU의 코드 재배치에 의해 엉키게 되면, 나와선 안되는 결과가 나올 수 있다. 따라서 우리는 이러한 코드 재배치를 신경쓰며 멀티 쓰레드 프로그래밍을 해야 한다. 예제 코드 - 인 상황이 로

Future 동기 vs 비동기 - 위 코드는 동기적이다. - 만약 Calculate가 굉장히 오랜 시간동안 연산하고, 그것을 기다리는 동안 다른 작업을 하고 싶다면? - 우리가 배운 내용을 토대로 아래와 같이 작성 가능하다. Thread 이용 - thread를 생성 후 task를 위임하여 비동기적으로 작동한다.= - 간단한 작업을 하는데도 불구하고, 굳이 쓰레드까지 만들어서 관리하기 귀찮다. - & 를 통해 해결 가능하다. + async에는 두가지 policy가 있다. Options 1) deferred - lazy evaluation : 지연해서 실행하세요 -테스트 결과 을 호출할 때가 돼서야 쓰레드로 분기되는듯? 2) async - 별도의 쓰레드를 만들어서 실행하세요 3) deferred | async - 둘 중 알아서 골라주세요 + 🏳️이 부분은 아직 모던 C++에 대해 배우지 않아 대충 이해만 하고 넘어갔다. 모던 C++ 학습 후 오른값 참조에

Condition Variable Condition Variable은 Event의 변종 앞선 Event 코드에서... - 생산자가 데이터를 넣고 파란불을 켜고, 소비자는 파란불을 확인하고 데이터를 꺼내고 빨간불로 바꾸고... 를 반복하면 q.size()는 0만 출력되지 않을까? - 실제로 실행해보면 데이터가 무한정 계속 늘어나는 것을 확인할 수 있다. 왜 데이터가 계속 늘어나는가? 1. 생산자가 데이터를 삽입하고 초록불로 바꿈 2. 소비자는 초록불을 확인하고 빨간불로 바꿈, 진입 3. !!여기서 생산자가 또 다시 데이터를 삽입하려고 함 4. 소비자는 락을 걸고 큐 사이즈를 읽어야 하는데, 이미 생산자가 락을 건 상태 ㅠㅠ 5. 결과적으로 다음에 운 좋게 락이 풀렸을떄 큐에서 pop하고 사이즈를 읽는데, 이때는 이미 큐에 여러개의 데이터가 삽입된 상태임. Consumer - 따라서 이런경우 if 대신 while을 사용하여 큐를 전부 비워주는 등의 조치를 취해야 함. Conditio

Event 난 소중하니 직원한테 부탁 (갑질메타) 예제 - 생산자() 쓰레드는 10초 마다 한번씩 생산하고, 소비자() 쓰레드는 바쁜 대기를 통해 계속해서 CPU 코어를 점유함. - 한 번 데이터를 소비하기 위해 10초동안 코어를 점유하는 것은 너무나 비효율적임. - 큐에 데이터가 들어올때 알려주는 무언가가 있으면 좋을 것 같다. = Create Event HANDLE CreateEventW(LPSECURITY lpEventAttributes, BOOL bManualReset, Bool bInitialState, LPCWSTR lpName) - 는 커널에서 만들어주기 때문에 라고도 불린다. - 커널에서 관리하는 오브젝트다. - Usage Count : 해당 오브젝트를 사용중인 프로세스나 쓰레드의 수. 커널 오브젝트가 공통으로 가진다. - Signal / Non-Signal : 파란불, 빨간불 커널모드 간 이동 떄문에 오버헤드가 발생함 - 굉장히 자주 발생하는 작업에는

Sleep sleepfor, yield Spin Lock 코드에서 이어서 - 을 통해 일정 시간 CPU 제어권을 넘겨줄 수 있음 - 는 과 같으며 딱 한번 제어권을 넘겨줌. 프로세스가 block 상태로 전이

Spin Lock lock이 해제될때까지 바쁜 대기(busy waiting) 스핀락은 유저 레벨에서 무한 while 루프를 돌고 있기 때문에 쓰레드 교체를 하지 않고 계속 CPU 자원(코어를 계속 점유)을 소모하면서 버티는 것 -컨텍스트 스위칭이 발생하지 않음. Spin Lock 구현 ver 1. 실행 결과 ⭐️ TIP C++ 에서의 키워드 : 최적화를 하지 말아달라. - 왜 0이 안나오는가 ?? 1. 락이 걸려있는가를 확인한다. 2. 걸려있지 않으면 락을 걸고 통제권을 획득한다. - 위 경우에서 만약 두 쓰레드가 i. 번을 동시에 확인하여 락이 걸려있지 않음을 확인한다면? - 통제권을 함께 얻는 경우가 발생함. -i, ii 가 한 묶음으로 동작하지 않음! - 즉, 원자성이 보장되지 않음. - 해결방안 - 가 한 묶음으로 동작해야 함. ver 2. ⭐️ TIP 에는 volatile이 포함되어 있다! 실행 결과 참조 링크 CAS 란?

Mutex - atomic은 일반적인 상황에서 쓰이기 힘들다. - 객체에 대한 원자성을 보장해야 하는 일이 훨씬 많기 때문 Mutex 문제 발생 코드 실행 결과 - 오류 발생 이유 : vector는 크기가 2^n에 도달했을때 기존 capacity의 두배가 되는 공간을 새로 할당받고 기존 공간을 없애는데, 원자성 보장이 되지 않기 때문에, 이미 없어진 공간을 다시 없애려 하기 때문. - 으로 미리 20000크기의 공간을 할당받으면 오류는 사라지지만, 여전히 원자성은 보장이 되지 않아 결과가 20000이 나오지 않음. Mutex Lock 실행 결과 - mutex lock을 통해 상호배제 달성 - 속도는 기존보다 많이 느려짐. - mutex lock은 재귀적으로 걸 수 없음. - m.lock(); m.lock();을 연속으로 하면 crash발생. - 재귀적 lock을 허용하는 recursive mutex에 관해서는 추후 학습. RAII(Resource acquisition is

원자성 - 각 쓰레드가 임계영역에서 경쟁(경합)할때, 공유자원에 대한 일관성이 보장되지 않는다. - a++의 경우 - load a - a + 1 - store a - 위 과정이 CPU instruction level에서 일어나는데, 이 중간과정에 다른 쓰레드의 instruction이 개입하면 결과의 일관성이 보장되지 않음. atomic 을 통해 통합 원자성 라이브러리를 추가할 수 있다. int 사용 실행 결과 atomic 사용 실행 결과 - atomic의 경우, 일반 int와의 구분을 위해 , 등과 같이 사용하는 것이 좋다. - 그냥 을 사용해도 똑같이 동작한다. 내부적으로 오버로딩이 되어있기 때문.

C++ 쓰레드 Windows IOCP기반 Stateful Server 구현에 관한 학습 내용을 정리한 것입니다. Linux OS 및 epoll 기반의 서버 구현과는 다소 차이점이 있을 수 있습니다. 쓰레드 기본 - 하나의 프로세스는 여러개의 쓰레드로 분리할 수 있다. - 쓰레드는 같은 프로세스 내의 힙과 데이터 영역을 공유하고, 개별적인 스택영역을 갖는다. - TCB를 통해 관리된다. - CPU 코어 개수 = 쓰레드의 개수 일 때 가장 이상적(ideal)임. \ api Type.h를 통해 타입의 이름이 변경된 부분이 있습니다. 예) int32, int64, ... - : 쓰레드의 id 확인, 유효하지 않은 쓰레드는 0 - : 사용 가능한 CPU 코어 개수 확인 - : 쓰레드를 stb::thread 객체에서 분리. 더 이상 join할 필요 없음 - linux의 데몬 프로세스와 유사함. - : 해당 쓰레드가 join 가능한 상태인지 확인. - : 쓰레드 종료를 기다림