목표
프로세스의 상태 변화와 프로세스 중 cpu 수행 단위인 스레드에 대해 알아본다.
스케줄러
- 스케줄러라는 별도의 이름을 가지고 등장했지만, 운영체제 안에 있는 코드 중 일부다!
프로세스 상태도
Suspended Blocked와 Suspended Ready
- 두 상태 모두 메모리를 통째로 빼앗겨서 메모리가 없는 상태
- 외부에서 빼앗은거니까, 외부에서 메모리를 다시 줘야 한다. 운영체제가 빼앗은거면 여유가 생기면 다시 Active 상태로 올려주거나, 사람이 정지시켰으면 사람이 재개시켜야 위로 올라간다.
- suspended는 아무것도 안하는 상태라고 설명했었는데, 그렇지는 않다는걸 알 수 있다.=> 메모리를 통째로 빼앗겼으니까 컴퓨터 내부에서 cpu작업은 일절 할 수가 없다. 그러나 i/o 를 하던 도중에 suspended로 들어갔으면 그 i/o작업은 할 수 있다. i/o 작업이 끝나면 suspended blocked 에서 suspended ready로 넘어간다.
swap out: 메모리에서 통째로 쫓겨나는 것
swap in: 메모리로 들어오는거
user mode에서 Running과, 커널 모드(monitor mode)에서 Running을 나눠놨다. => 어떤 프로세스가 자기 코드를 수행중이면 user mode에서 running이다. 만약 프로세스가 i/o작업이나 본인이 할 수없는 일을 운영체제한테 부탁할 때 system call을 한다. 그래서 운영체제 코드가 수행중일 때 운영체제가 cpu를 잡고 기계어를 실행하니까, '운영체제가 running이다.'라고 생각하기 쉬운데 그건 아니고, running ready blocked 운영체제가 사용자 프로세스를 관리하기 위한 상태지. 운영체제 본인의 상태를 표현한것이 아니다.
예시1) 자기 코드를 수행할 때 user mode에서 러닝, 시스템 콜을 해서 커널모드에서 running을 한다.
예시2) a프로그램이 돌아가다가 디스크 컨트롤러가 인터럽트를 발생시켰다. i/o 요청을 한 다른 프로그램이 끝났다고 알려준 것. a의 상태는 running이였다가 인터럽트 때문에 운영체제한테 뺏겼다. 본인과 상관없는 이유 때문에 인터럽트가 들어와서 cpu가 운영체제한테 넘어갔지만 여전히 a가 running하고 있다라고 간주한다.
예시3) i/o와 관련된, 디스크 i/o 인터럽트는 하드웨어 인터럽트인가? 소프트웨어 인터럽트인가? 둘다 이다!!! 프로그램이 디스크 i/o를 하기위해서 본인이 요청할 수 없기 때문에 운영체제한테 요청을 한다. 즉 i/o를 시작할 때 시스템 콜을 해서 운영체제한테 요청을 하면 운영체제가 cpu를 잡고 있으면서 어떤 기계어를 실행하냐하면 cpu가 디스크 컨트롤러한테 i/o좀 실행해주세요 요청을 한다. => 소프트웨어 인터럽트. i/o 실행이 다 끝나서 디스크 컨트롤러가 i/o다 끝났음 cpu한테 알려주는건 => 하드웨어 인터럽트다.
결론) 사용자 프로그램이 실행되다가, system call, interrupt, trap과 같은 하드웨어 소프트웨어 각종 인터럽트가 들어와서 cpu가 운영체제한테 넘어갔더라도 방금 전 그 프로세스가 여전히 running하고 있다.!!! 단 커널 모드에서.
프로세스 상태도 그릴 줄 알아야 함 !!!
Thread
Thread: 프로세스 중에서 cpu 실행 단위
Process는 메모리 주소공간에 Stack, Data, code가 있고. 운영체제가 이런 process를 관리하기 위한 PCB를 하나씩 두고 있다.
현재 프로그램 카운터, 코드의 어느 부분을 실행했으며/ CPU에 실행되면서 REGISTER에 어떤 값을 넣고 있었는가/ 메모리에는 어떤 값을 가지고 있고/ 전역변수가 어떤게 있고/ 코드에서 함수 실행을 하면서 STACK에다가 함수 실행이 몇개가 쌓여있는가. 이런게 PROCESS를 나타내고 있다.
각각의 프로그램을 다 실행시키는 PROCESS는 대단히 비효율적이다. => thread 탄생! => 동일한 프로그램을 여러개 띄우더라도 프로세스가 한개 만들어진다. 즉 code, data, stack 구조가 한개가 만들어지고, 대신에 각각의 서로 다른 부분의 코드를 실행할 수 있으니 그것만 따로 관리를 해주자. => cpu의 실행 단위. cpu를 어디 실행하고 있는지에 대한 정보.
이게 얼마나 효율적이냐하면~~
a프로세스에서 b프로세스로 넘어가는 contack switch는 오버헤드가 정말 많은 작업이다. 동일한 프로세스 안에서 thread1 => thread2로 넘어가는건 값비싼 오버헤드가 필요없다. 되게 효율적이다.
하나의 프로그램에서도 여러 thread를 이용해서 소프트웨어를 만들수도 있다.
근데 chrome은 동일한 웹브라우저 띄울때 독립적인 process를 둔다. thread를 안하고 보안상의 문제 때문에? 그래서 구현을 어떻게 하느냐~~ 달려있다.
pcb라는 것은 프로세스 하나를 관리하기 위한 구조다. 이 프로세스 안에 thread가 여러개가 있다면 프로세스에서 thread에 필요한 정보, 즉, cpu관련 정보만 따로 뽑아서 관리한다!
single and multithreaded processes
benefits of threads
Implementation of Threads
thread 구현 방법은?
1) thread를 이미 운영체제가 알고 있는 경우가 있다. => kernal threads
: 운영체제가 cpu 스케줄링 할 때 이번에는 aprocess 에서 bprocess 한테 넘겨야지를 커널이 thread를 알면 athread에서 bthread로 넘겨야지 이렇게 된다.
2) 운영체제가 thread의 존재를 모른다. => user threads
: 운영체제는 그 프로세스한테 cpu를 준다. 그러면 그 process 내부에서 athread를 실행하다가 a가 i/o 입출력을 하게 되면 운영체제한테 비동기식 입출력을 요청해서 다시 cpu를 받은 다음에 bthread한테 cpu를 넘기고 ,, 이런식으로 사용자 프로그램 단에서 thread를 관리하는 것
