Falling in Love with Coding

크리티컬 센션(임계 영역) 기반의 동기화 - 일종의 Key(열쇠)를 가지고 접근하도록 하게 함 CRITICAL_SECTION gCriticalSection; // 임계영역 오브젝트(Key에 해당) InitializeCriticalSection(&gCriticalSection); // 오브젝트 초기화(동기화 작업 준비) ..... // 임계영역 진입을 위해 임계영역 오브젝트 획득 EnterCriticalSection(&gCriticalSection); // 열쇠 획득 /*임 계 영 역 */ // 임계영역 오브젝트 반환 LeaveCriticalSection(&gCriticalSection); // 열쇠 반환 ..... DeleteCriticalSection(&gCriticalSection); // 열쇠 소멸..

- 임계 영역 => 둘 이상의 쓰레드가 동시에 동일한 메모리 영역에 접근하도록 하는 코드 블럭 : 메모리 접근 동기화가 필요 - 여러 쓰레드의 실행 순서가 필요한 경우 : 순서 동기화(Chapter 14에서 다룰 예정) 쓰레드 동기화 기법의 두 가지 구분 : 유저 모드 동기화, 커널 모드 동기화 동기화 기법 유저 모드 동기화 커널 모드 동기화 Pros 커널 모드와의 빈번한 이동이 없기에 속도가 빠름 다양한 기능을 다룰 수 있음 Cons 커널 모드보다 기능이 제한적 유저 모드와의 이동으로 속도가 느림 유저 모드 동기화 - 크리티컬 섹션(임계 영역) 기반 동기화 - 인터락 함수 기반 동기화 커널 모드 동기화 - 뮤텍스 기반 동기화(접근 동기화) - 세마포어 기반 동기화(접근 동기화) - 이름있는 뮤텍스 기반..

쓰레드의 상태 컨트롤 - [SuspendThread] 함수는 Running 상태의 쓰레드를 Blocked 상태로 만들어 주는 함수 - [ResumeThread] 함수는 Blocked 상태의 쓰레드를 Ready 상태로 만들어 주는 함수 * 명시적으로 쓰레드를 컨트롤하는 것은 문제를 발생을 야기시킬 수 있기에 가급적 사용을 하지 않음 쓰레드의 우선순위 결정 요소 - 기본 우선순위는 9가 됨 쓰레드의 우선순위 컨트롤 함수 // 쓰레드의 우선순위를 설정하는 함수 BOOL SetThreadPriority { HANDLE hThread, int nPriority } // 함수 실패 시 0(False)을 반환 // 쓰레드의 우선순위를 반환받는 함수 int GetThreadPriority { HANDLE hThread..

- 쓰레드는 스택 영역만 독립적으로 같고 그 외 힙, 데이터, 코드 영역은 공유 - 각각의 쓰레드가 전역변수 total에 접근하여 연산한 값을 저장 문제점 - total 변수에 다중으로 접근 시 total에 값을 넣기 전에 쓰레드 간의 CS(Context Switching)이 발생하는 경우 - total에 접근 중인 쓰레드가 있으면 다른 쓰레드는 접근할 수 없도록 해야 함(임계 영역 문제-Code Block) 프로세스로부터의 쓰레드 분리 1) 쓰레드 Usage Count : 생성과 동시에 2 2) 하나는 쓰레드 종료 시 감소, 하나는 CloseHandle 함수 호출 시 감소 3) 쓰레드 생성 후 종료코드를 얻은 다음 [CloseHandle] 함수 호출 : 쓰레드 분리* ANSI 표준 C 라이브러리와 쓰레..

쓰레드의 생성 - CreateThread 함수를 통해 쓰레드를 생성 ㄴ 첫 번째 전달 인자: 핸들의 상속여부 결정 ㄴ 두 번째 전달 인자: 초기 독립 스택의 사이즈 ㄴ 세 번째 전달 인자: void 포인터를 인자로 받고 DWORD를 리턴하는 함수의 포인터(쓰레드 메인함수) ㄴ 네 번째 전달 인자: Windows에게 요구할 전달인자 선언 ㄴ 다섯 번째 전달 인자: 쓰레드를 생성과 동시에 Blocked 상태로 둘 지에 대한 옵션 여부 ㄴ 여섯 번째 전달 인자: 고유한 쓰레드의 ID cf) 핸들은 프로세스가 컨트롤하기 위한 것 생성 가능한 쓰레드의 갯수는? - 허용 가능한 범위 안에서 최대한 생성 가능 - 별도 사용 스택 공간의 최대치 만큼 생성할 수 있음 쓰레드의 소멸 case 1) 거의 대부분의 경우 : ..

Windows에서의 프로세스와 쓰레드 - 프로세스A와 프로세스B가 있으며, 프로세스A는 3개의 쓰레드, 프로세스B는 2개의 쓰레드가 있다면, - 프로세스A의 쓰레드1,2가 동시 실행 중이면 쓰레드3은 Block상태 즉, I/O연산 중에 있거나 우선순위가 낮기 때문 - 쓰레드와 프로세스를 구분하기는 어렵지만 '프로세스 내에 존재하는 실행의 흐름'으로 간주 - 쓰레드는 메인 코드가 있으며 독립된 스택 영역을 사용 - 실행 흐름의 주체는 프로세스가 아니라 쓰레드(메인 함수 호출 또한 메인 쓰레드에 의해 실행 됨) - 쓰레드가 실행할 수 있는 환경을 제공해주는 것이 프로세스이며, 그 환경 안에서 쓰레드가 동작 쓰레드 구현 모델에 따른 구분 Kernel Level Thread와 User Level Thread O..

- 멀티 프로세스는 둘 이상의 프로그램을 실행시키기 위해 필요 - 하나의 프로그램은 하나의 흐름을 가지고 실행 ex) 테트리스에서 멀티 플레이로 2명이 동시에 진행(흐름이 2개) ㄴ 하나의 프로그램 내에서 둘 이상의 실행 흐름을 가짐 ㄴ 하나의 흐름 안에 Context Switching으로 인해 여러 프로세스의 실행으로 보이게 됨 ㄴ 시작은 부모 프로세스로 시작하지만 자식 프로세스가 생성되어 여러 흐름으로 프로그램이 실행됨 - 프로세스A와 프로세스B가 Code영역을 공유하여 사용해도 무방하지만 각 프로세스가 사용하는 함수를 동일한 Stack영역을 사용하게 되면 성능에 문제가 발생 : A와 B가 동시에 사용하게 되면 스택에 쌓이는 순서와 호출 순서가 뒤섞이게 됨 - 이러한 문제를 해결하기 위해 만들어진 것..

함수 호출에 의한 실행의 이동과 PC - CPU는 PC(Program Counter) Register에 할당된 주소의 함수를 실행 - 함수 호출에 의한 실행의 이동은 PC Register의 값을 변경하는 것 : 함수 호출 - PC Register도 다시 돌아갈 함수의 주소를 백업하기 위해 LR(Link Register)를 활용 - LR은 FP와 동일하게 스택 메모리에 백업 함수 호출 규약 - C 스타일은 오른쪽에서 왼쪽으로 스택에 쌓음 cf) P(Pascal) 스타일은 왼쪽에서 오른쪽으로 쌓음 - 32비트 보다 64비트에서 더 많은 레지스터를 사용

함수 호출 인자의 전달방식 - 실제로는 역순으로 스택 메모리에 채워짐(8이 먼저, 그리고 7이 저장 됨) - "SP가 가리키는 현재 위치에 전달되는 인자값을 저장하고 나서, SP를 증가시켜 다음 메모리 주소를 가리키게 한다." 함수 호출 인자의 전방식의 문제점 - (STORE 대상 레지스터, 목적지 메모리 주소)로 명령어를 전달해야 되기 때문에 STORE 7, sp 와 같은 명령어를 사용할 수 없음 - 이를 해결하기 위해 2가지 명령어를 사용해야 함 1) 숫자 7을 레지스터에 저장하는 명령어: ADD r1(레지스터), 7, 0 으로 7을 r1 레지스터에 저장 2) sp를 메모리에 저장하는 명령어: STORE sp, 0x40 PUSH 명령어 완성 ADD r1, 7, 0 STORE sp, 0x40 STORE..

스택 프레임(Stack Frame) - 함수 별로 선언된 변수들의 메모리 공간의 구분 - 다음에 저장할 메모리 주소를 레지스터의 SP(Stack Pointer)에 저장 FP Register - 레지스터에는 반환 후 SP 위치를 알지 못함 - 반환 후 되돌아갈 주소를 저장하는 레지스터 공간은 FP(Frame Pointer) Register - 다시 말하면 FP는 SP의 백업 FP Register 문제점 - 함수 내 함수 호출이 반복적으로 실행되면 FP가 덮어쓰게 됨 - 이를 해결하기 위해 FP의 백업이 필요 FP Register 해결책 - 스택 메모리를 FP의 백업으로 사용 - FP가 덮어쓰기가 되기 전 SP가 가리키는 메모리 주소에 현재 FP의 주소 값을 저장 - 반환은 이를 역순으로 사용 정리 1. 메..