Falling in Love with Coding

쓰레드의 생성 - 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. 메..

일반 OS와 리얼타임(Real Time) OS의 차이점 - 두 OS를 결정짓는 요소는 스케줄러 - 리얼타임은 다른 말로 실시간을 뜻함 └ 프로그램 실행 시 즉시 실행되도록 스케줄링 함 └ 응답성이 좋지만 프로그램 속도가 빠른 것은 별개 - OS는 클럭을 기준으로 타임 슬라이스(Time Slice)를 정함 └ 일반적으로 1ms를 1 TS - 일반 OS는 TS가 크고, 리얼타임 OS는 상대적으로 작음 선점형 OS와 비선점형 OS - 우선순위가 높은 것을 먼저 실행해야 하는 것이 OS의 의무 - 선점형 OS의 스케줄러는 우선 순위가 낮은 것을 즉시 뒤로 밀어내고 우선 순위가 높은 것이 먼저 실행 됨 └ 상대적으로 스케줄러가 하는 일이 많음 └ 스케줄러가 더 많이 프로세스의 실행에 직접적으로 관여함 - 비선점형..

IPC별 특성 메일슬롯 이름없는 파이프 이름있는 파이프 방향성 단방향, 브로드캐스팅 단방향 양방향 통신범위 제한 없음 부모 자식 프로세스 제한 없음 이름없는 파이프 - PC 이름이 없음을 의미 - 부모 프로세스가 만들 파이프를 통해 서로 데이터를 송/수신할 수 있음(위험 요소로 작용) 이름있는 프로그래밍 모델 1) CreateNamedPipe 함수를 통해 파이프를 생성하지만 바로 외부와 통신은 불가 2) ConnectNamedPipe 함수로 연결 대기 상태로 전환 3) Client의 CreateFile 함수 호출에 의해 파이프에 연결하여 데이터를 송/수신 예제) NamedPipe_Server.cpp #include #include #include #include #define BUF_SIZE 1024 i..

핸들테이블의 이해 - 핸들 테이블은 프로세스마다 독립적 핸들테이블의 상속 - CreateProcess 함수에서 5번째 인자 값으로 bInheritHandles라는 BOOL 값에 따라 핸들테이블 상속이 가능 - 핸들 테이블의 데이터 마다 상속 여부가 있으며, Y가 되어 있는 핸들 데이터만 상속이 가능 ex) 핸들 테이블 예시 핸들 주소 상속여부 127 0x1200 Y 168 0x1680 N 256 0x2400 Y ..... SECURITY_ARRTIVUTES sa; sa.nLength = sizeof(sa); sa.lpSecurityDescriptor = NULL; sa.bInheritHandle = TRUE; // 핸들 상속 여부 ..... CreateMailSlot(....&sa); // &sa는 4번..

프로세스 환경변수의 구성 환경변수 데이터를 저장하는 함수 : SetEnvironmentVariable("Key", "Value"); 환경변수 데이터를 가져오는 함수 : GetEnvironmentVariable("Key", 반환할 포인터 변수,); * 환경변수 테이블은 자식 프로세스에게 복사하여 보낼 수 있음 ex) EnvParent.cpp #include #include #include int _tmain(int argc, TCHAR* argv[]) { SetEnvironmentVariable(_T("Good"), _T("morning")); SetEnvironmentVariable(_T("Hey"), _T("Ho!")); SetEnvironmentVariable(_T("Big"), _T("Boy"));..