데이즈

안녕하세요? 허니입니다. 운영체제의 프로세스의 처리 속도를 어떻게 하면 성능 효과를 볼 수 있을까요? 하드웨어는 고정된 성능과 자원을 제공하기 때문에 이를 효과적으로 활용하는 것이 프로세스의 처리 속도를 향상시키는 키가 될 수 있습니다. 이번 주제는 프로세스 관리가 어떻게 되는지를 알아야 이해하실 수 있으니 프로세스 관리에 대해 먼저 선행 스터디를 하시고 읽어주세요.

오늘의 주제

 Process의 처리속도를 높이고 싶다면

만약 하나의 컴퓨터 시스템에 3개의 CPU를 설치한다면 처리속도 역시 3배로 빨라질까

컴퓨터의 사용영역이 계속 확대되면서 사용자들은 좀 더 빠른 처리속도를 원하게 되었다. 많은 전문가들은 보다 빠르게 보다 많은 양의 작업을 처리하기 위해 여러 방법을 고려했다. 그 중 한가지 방법이 바로 CPU의 개수를 늘리는 것이었다. 그러나 CPU의 개수를 늘려 놓았는데도 처리속도가 빨라지지 않아 한때 시스템 설계자들은 매우 의아해하였다. 그렇다면 무엇이 문제였을까. 컴퓨터에 있어서 인간의 두뇌와 같은 CPU의 개수가 처리능력에 향상을 가져오지 못하다니 말이다. 바로 각각의 CPU가 처리해야 할 작업을 나누어 놓지 않았기 때문이었다. 다음과 같은 예를 하나 들어보자. 어느 컴퓨터 내부에 3개의 CPU를 설치해 놓았다고 생각해보자. 이 3개의 CPU가 처리해야 하는 계산은 총 30번인데 1번의 계산에 1초씩의 시간이 걸린다. A의 시스템에서는 3개의 CPU 설치 이후 더 이상의 조절작업을 하지 않아 CPU가 직렬연결 상태라면 30번의 계산은 다음 그림과 같이 수행된다. 그렇기 때문에 CPU가 하나인 컴퓨터 시스템과 계산속도의 차이가 없는 결과가 나타나게 되는 것이다.

그림 5 CPU의 직렬연결

바로 CPU가 1개이건 2개이건 작업이 일렬로 처리될 때는 속도에 별다른 차이가 없는 것이다. 바로 주어진 작업을 CPU마다 병렬처리로 조정해 놓아야만 3개의 CPU가 10개씩의 계산을 분담해 동시 처리가 가능해 지는 것이다. 다시 말해 30초의 작업시간이 10초로 빨라질 수 있는 것이다. 다음의 그림과 같이 말이다.

그림 6 CPU의 병렬연결

그러나 컴퓨터 시스템의 처리속도를 높이는 것과 관련된 문제는 여기서 끝나지 않았다. CPU가 2개 이상일 때 이것을 통해 동시에 수행되는 프로세스를 운영체제 구조적으로 뒷받침해줄 수 없는 것이다. 그것은 바로 커널 스택이 하나라는 OS구조상의 문제가 표면으로 나타난 것이다. 사용자영역의 프로세스들이 커널 스택의 사용을 위해서 차례를 기다려야 하는 것이다. CPU가 하나일 경우에는 커널 스택이 하나라는 것이 작업을 수행되는데 걸림돌로 작용하지는 않았었다. 그러나 CPU가 3개일 때 3개의 프로세스가 동시 처리가 가능해진다면 어떨까. 이를 구체적으로 설명하기 앞서 스택의 역할을 살펴보기로 하자. 메모리를 쪼개어보면 다음과 같은 process image가 나타난다.

그림 7 Process Image

스택은 프로그램이 수행되기 위한 모든 정보를 갖고 있는 부분으로 프로세스가 수행되는 동안 계속해서 변화되는 수행값을 저장하기 위해 메모리 확보를 하게 된다. 또한 스택포인터라는 것은 가장 최근 스택에 삽입된 자료의 위치를 가리키고 있는 포인터를 말한다.

잠깐, 상식! 포인터란 어떤 하나의 자료가 저장되어 있는 메모리의 위치 또는 주소를 가르키는 정보를 말한다. 프로그램에서는 이러한 정보를 통하여 자료가 저장되어 있는 위치로 직접이동할 수 있다.

예를 들어 97년 한 해 동안 A라는 학생은 국어시험에서 다음과 같은 성적을 얻었다.

* 1학기 중간고사 80점, 기말고사 90점

* 2학기 중간고사 70점 기말고사 100점

총 평균 점수를 계산하는 프로그램을 수행한다면 그 수행과정에서 스택은 어떤 역할을 할까. 평균점수를 얻어내기 위해선 4번의 시험점수를 더하는 처리와 최종적으로 더한 값을 4로 나누는 작업이 이뤄져야 한다. 이 작업을 1학기 점수를 계산하는 프로세스 1과 2학기 점수를 계산하는 프로세스 2로 나누어 수행한다고 생각해보자. 프로세스 1이 계산한 80+90=170에서 170이라는 결과값이 바로 스택에 기억되어 다음 처리를 가능하게 해주는 것이다. 170이라는 점수가 저장되어 있어야만 프로세스2에 의해 2학기의 국어성적을 더할 수 있기 때문이다. 스택은 프로세스가 계산을 수행할 때마다 메모리를 확보해 임시 변수들을 저장하는 공간이다.

그림 8 스택의 역할

잠깐, 상식! data segment : 작업을 처리하기 위한 자료(하나의 사실이나 숫자 통계치)등의 함수를 갖고 있는 부분으로 내용의 값을 디스크에서 가져온다.

여기에서 잠깐 함수라는 개념을 짚어보자.

우리가 그림 2-9에서 A학생의 국어 평균점수를 계산해 보았다. 그렇다면 고려고등학교 모든 학생의 평균국어성적을 계산해 본다면 어떨까. 뭔가 보다 간편한 처리가 있어야 할 것 같지 않은가. 함수를 정의해 보자면 프로그램 내에서 자주 쓰는 기능들을 좀더 편리하게 사용할 수 있도록 정의해 놓은 것이다. 함수는 프로그래머의 의도에 따라 정의되기도 하고 이미 다른 사람에 의해 정의된 함수가 사용되기도 한다.

text segment code : 컴퓨터 시스템이 이해할 수 있는 기계어 부분으로 내용의 값을 디스크에서 가져온다. 모든 컴퓨터의 기본적인 언어는 0과 1의 배열로 이루어져 있다. data를 처리하기 위해 CPU를 가동시키려면 프로그램은 기계어 형태로 되어있어야 한다. 우리가 어디선가 들어 봤음직한 어셈블리어가 바로 이러한 기계어들인 것이다.

 질문) 프로그램을 수행하다 만약 스택 영역이 부족해지면 어떻게 될까.

 답) 이러한 경우 커널에 의해 자동처리가 된다. 스택으로 할당받은 공간이 가득 차서 스택 포인터가 그 범위 바깥을 접근하게 되면 자동적으로 segmentation fault가 생기고 이렇게 되면 커널이 모자라는 스택 영역을 보충해준다.

지금까지 스택의 역할을 살펴보았다. 그렇다면 앞서 언급한 커널 스택의 문제를 다시 짚어보자. 여러 개의 CPU가 사용되고 있는 경우 커널스택이 하나라면 어떤 일이 발생할까. 예를 들어 벽돌 쌓는 작업을 하는 인부는 여러 명인데 벽돌을 나르는 인부는 1명뿐이라고 가정한다면 어떨까. 벽돌 나르는 인부가 가져다준 벽돌을 모두 쌓은 후 다시 나에게 벽돌이 돌아올 순서가 오지 않는다면 그는 어쩔 수 없이 손을 놓고 있어야 함으로 작업 진척이 더딜 것이다. 마찬가지로 하나의 CPU만이 스택을 사용하게 됨으로 계속 수행-멈춤-수행-멈춤을 반복할 수밖에 없는 것이다. 다시 말해 자신이 작업할 영역을 확보해 줄 때까지 CPU는 아무 일도 할 수 없는 상황인 것이다.

그림 9 커널 스택이 하나일 경우

요점정리

 작업의 처리속도를 높이기 위해서는 CPU가 1개이건 2개이건 작업이 일렬로 처리될 때는 속도에 별다른 차이가 없는 것이다. 바로 주어진 작업을 CPU마다 병렬처리로 스케줄 해놓아야만 동시 처리가 가능해 처리속도가 향상된다.

 CPU 병렬 연결만 해놓으면 속도 향상의 모든 문제는 해결되나?

CPU가 2개 이상일 때 운영체제 구조상의 문제가 어려움으로 발생되었다. 그것은 바로 커널 스택이 하나라는 OS 구조상의 문제가 표면으로 나타난 것이다. CPU가 하나일 경우 커널스택 역시 하나이기 때문에 작업이 수행되는데 걸림돌이 존재하지 않지만 만약 CPU가 3개여서 3개의 프로세스가 동시 처리가 가능해진다면 어떨까. 사용자영역의 프로세스들이 커널 스택의 사용을 위해서 차례를 기다려야 하는 것이다.

 커널 스택 문제의 해결 방안은?

커널 내의 스택이 하나이기 때문에 처리속도가 떨어지는 것을 걱정한 시스템 설계자는 커널스레드를 구상하기 시작했다. 바로 커널스레드 각자가 스택을 가짐으로써 처리속도가 증대되는 것이다.

안녕하세요? 허니입니다. 운영체제에서 가장 중요하다고 볼 수 있는 프로세스는 각 프로그램이 돌아가는데 있어 많은 역할을 하고 있습니다. 때문에 프로세스 관리가 매우 중요하기 때문에 프로세스가 어떻게 처리 되는지에 대해 잘 알아야 하기에 포스팅을 하겠습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 프로세스 관리는 왜 필요한가?

 Process는 어떤 과정으로 처리되어지나?

프로세스 관리는 왜 필요한가?

하나의 컴퓨터 시스템이 오직 한 사람의 사용자만을 위해 존재하고 한번 컴퓨터가 작동할 때 하나의 프로세스만이 작업을 수행한다면 아마도 프로세스 관리라는 말은 나올 필요가 없었을 것이다. 그러나 이러한 시스템이 어딘가 존재한다면 그것은 이미 컴퓨터이기를 포기한 물건일 것이다. 이 시대 컴퓨터 시스템은 하나의 시스템 내에서 통신을 통해 파일을 다운 받으면서 한글 문서를 작성할 수 있듯이 동시에 여러 프로그램의 사용이 가능하다. 또한 대용량의 중앙처리컴퓨터를 놓고 여러 대의 모니터가 설치되어 사용되기도 하고 수천 명이 동시에 PC통신에 접속하기도 한다. 이렇듯 여러 작업이 동시에 이뤄질 때 프로세스들을 제대로 관리하지 않으면 처리가 느려질 것이다. 두말하지 않더라도 결과는 뻔할 것이다. 모든 시스템 사용자들은 자신이 요구한 결과들이 느릿느릿 처리된다면 엔터 키를 계속 내려치거나 대단히 화난 얼굴로 컴퓨터 모니터를 노려볼 것이다. 성격이 급한 사람은 당장 컴퓨터 회사에 전화를 걸어 고장신고를 할지도 모르겠다. 바로 이러한 문제를 피하기 위해 프로세스를 보호해주고 프로세스마다 작업 시간을 할당해주고 그 작업에 우선 순위를 매기는 등의 작업이 바로 프로세스 관리(process management)이다.

프로세스들은 어떤 과정으로 처리되어지나?

하나의 프로세스가 수행되는 동안 시스템 콜에 대한 작업은 어떻게 수행될까. 또한 우선순위가 높은 프로세스가 존재한다는 것은 과연 어떻게 알 수 있을까. 하나의 프로세스처리 과정 중 발생하는 이러한 문제를 해결하기 위해 시스템 설계자는 다음과 같은 조금은 복잡하다고 느껴지는 처리 과정을 구상해 내었다.

그림 1 프로세스 처리과정

위의 그림을 다시 한번 설명하자면,

 1. 사용자 영역(user mode)에서 프로세스A가 수행되고 있다.

 2. 시스템 콜이 호출된다. 수행되던 프로세스 A는 트랩이 걸리고 수행영역은 사용자영역(user mode)에서 커널영역(kernel mode)으로 이동된다.

 3. 커널영역에서 호출한 시스템 콜 작업이 수행된다.

 4. 작업 수행 후 상태에 따라 running 큐나, sleep 큐에 넣는다.

 5. 프로세스A의 인터럽트 이후 처리를 수행하기 이전 보다 우선순위가 높은 프로세스가 있는가를 확인하기 위해 디스패춰(dispatcher)를 부른다.

 6. 디스패춰를 통해 보다 우선순위가 높은 프로세스 B를 선택한다.

 7. 프로세스B로 점프하여 먼저 처리한다.

잠깐, 상식! * 사용자영역(user mode) : 컴퓨터 시스템의 영역 가운데 사용자에 의하여 요청된 프로그램에서 사용되고 있는 영역을 말한다. * 커널영역(kerel mode) : 프로그램이 OS에서 제공되는 기능을 이용하기 위하여 시스템콜     을 호출하여 현재 커널의 코드를 수행하고 있는 상태로 사용자가 요구한 작업을 시스     템 내부에서 처리하기 위하여 컴퓨터시스템이 차지하는 영역을 말한다. * 디스패춰 : 다중프로그래밍 시스템에서 대기열에 기다리고 있는 하나의 프로세스를 선택     하여 CPU의 사용권한을 부여하는 OS 스케줄러 프로그램의 한 부분.

이와 같이 7가지 과정으로 나뉜 프로세스 처리 과정을 살펴보았다. 그러나 단순한 시스템은 1,2,3,1의 과정을 반복한다.

그림 2 1,2,3,1의 과정

그러나 보다 정밀한 OS는 우선순위가 보다 높은 프로세스가 존재하는가를 확인하고 그것을 처리하기 위해 4,5,6,7의 과정을 밟게 되는 것이다. 그렇다면 앞서 언급했던 문맥전환(context switching)은 어느 순간에 이뤄지게 되는 것일까. 바로 6과 7 사이에서 문맥전환이 일어나게 된다. 우선순위가 보다 높은 프로세스가 존재한다면 CPU는 자신이 처리하던 프로세스A를 잠시 멈추고 프로세스B를 수행하게 되므로 문맥전환이 일어나게 되는 것이다. 만약 더 이상 높은 우선순위의 프로세스가 존재하지 않아 프로세스 A가 다시 선택되면 문맥전환은 일어나지 않는다.

그림 3 문맥전환(context switching)

그렇다면 이와 같이 복잡한 과정으로 프로세스를 수행하는 이유는 뭘까. 많은 세월 시스템 설계자들은 어떻게 하면 프로세스를 보다 많이 보다 빠르게 또한 보다 효율적으로(보다 급한 처리를 원하는 프로세스는 보다 빠르게) 처리할 것인가를 고민해 왔다. 그 고민은 하나의 시스템 설계 목표를 세우는데 이르렀다. 바로 처리량(throughput)을 높이고 응답시간(response time)을 낮게 하는 것이었다. 바로 프로세스를 보다 많이 보다 빠르게 처리하기 위한 방법이 7가지 프로세스 처리 순서를 만들어내게 한 것이다.

잠깐, 상식! *쓰루풋(throughput)이란? 주어진 시간에 시스템이 처리하는 일의 양 *반응 시간(response time)이란? 하나의 작업이 시작해서 끝날 때까지의 시간

지금까지 프로세스들이 어떤 방법으로 처리되는가에 대해 이야기해 보았다. 다음과 같은 질문들을 통해 보다 깊이 있는 내용을 살펴보자.

질문1) 커널영역에서 타임퀀텀이 다 되었을 경우에는 어떻게 수행하게 되나?

질문2) 디스패춰 호출을 했을 경우 프로세스A의 결과 값은 어느 영역에 저장되나?

질문3) 커널이 시스템 콜을 수행하고 있을 때 다른 프로세스가 수행될 수 있을까?

답1) 커널영역에서 타임퀀텀이 다 되었을 경우에는 적절한 순위의 수행큐에 저장되게 된다. 저장할 때 flag를 붙여놓아 다음에 취할 action을 표시하게 된다.

답2) 사용자 스택 (User stack) 즉 프로세스 스택에 결과값이 저장된다. (프로세스 스택의 개념은 이후 강의할 것임으로 일단은 설명을 접어두기로 하자.)

답3) 없다. 현재까지 CPU가 하나일 때를 가정한 것이기 때문이다. 여러 개의 프로세스를 만들어놨다 하더라도 실행 프로그램은 오직 하나이다.

요점정리

 프로세스 관리란?

프로세스를 보호해주고 프로세스마다 작업 시간을 할당해주고 그 작업에 우선 순위를 매기는 등의 작업이 바로 프로세스 관리이다.

 프로세스들은 어떤 과정?

 1. 사용자영역에서 프로세스A가 수행되고 있다.

 2. 시스템 콜이 호출된다. 수행되던 프로세스 A는 인터럽트가 걸리고 수행영역은 사용자영역에서 커널영역으로 이동된다.

 3. 커널영역에서 시스템 콜을 호출한 작업이 수행된다.

 4. 작업 수행 후 상태에 따라 수행, sleep queue에 넣는다.

 5. 프로세스A의 인터럽트 이후 처리를 수행하기 이전 보다 우선순위가 높은 프로세스가 있는가를 확인하기 위해 디스패춰를 부른다.

 6. 디스패춰를 통해 보다 우선순위가 높은 프로세스 2를 부른다.

 7. 프로세스2로 점프하여 먼저 처리한다.

안녕하세요? 허니입니다. 운영체제의 프로세스 생애주기(Process Life Cycle)에 대해 포스팅을 하려고 합니다. 프로세스 라이프사이클은 마치 한 사람의 삶의 모습과 닯아 있기 때문에 이해하기 쉬운 부분이 많습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 Process Life Cycle

Process Life Cycle

프로세스 라이프 사이클은 한 사람의 삶의 모습과 닮아있다고 말하고 싶다. 한 사람으로 태어나 성인으로 자라 한 사람으로서 자신의 몫을 다하고 어떠한 삶의 역경에 부딪혀 잠시 주저 앉기도 하고 또다시 자신의 몫을 찾아 역할을 다하다 결국에는 인생을 마감하는, 그런 인간의 모습 말이다. 프로세스 라이프 사이클을 고안해낸 사람 역시 어떤 한 인간이었기에 그 모습이 서로 닮아있을 수밖에 없을 것이다. 프로세스로 생성되어 자신의 역할을 할 때까지 기다림을 갖고 자신의 몫을 할 순간에는 그 역할에 충실하고 또한 어떤 문제의 부딪혔을 때 잠시 자신의 자리를 내어주기도 한다. 그리고 자신의 자리를 되찾아 하나의 프로세스로서의 역할을 다하고 마감되는 그 모습을 이해하는데 우리는 별다른 어려움이 없을 것이다.

프로세스 라이프 사이클은 다음과 같은 5단계로 나뉜다.

1. 생성 - 디스크에서 메모리로 프로그램이 올라가 실행준비를 하는 상태

2. 준비 - 순서에 맞춰 처리를 기다리는 상태

3. 수행 - 작업이 처리되고 있는 상태

4. sleep(=blocked)- 프로세스가 잠시 어떠한 조건에 의해 작업이 이뤄질 수 없는 상태로 그 조건이 해결되기를 기다리는 상태

5. 종료

이 과정에서 주의해야 할 점은 준비상태의 프로세스와 sleep 상태의 프로세스는 각각의 list를 작성해야 한다. 준비리스트에 있는 프로세스들은 각각 우선순위가 주어져 가장 높은 우선 순위의 프로세스의 차례로 CPU를 차지하게 된다. 그러나 sleep 리스트는 순위가 없다. 왜냐하면 대기상태에서 벗어나는 것은 정해진 순위에 의해서가 아니라 대기상태로 머물러야 했던 그 어떤 조건들이 해결되면 다시 실행 상태로 돌아갈 수 있기 때문이다.

그림 15 프로세스 라이프 사이클

a. 생성과정에서 준비상태로의 이동과정에서는 프로세스가 처리되기 위한 메모리와 필요한 주변장치들이 체크된다.

b. 준비상태에서 수행상태로의 이동과정에서는 미리 정해진 알고리즘(FCFS, SJN 등은 이후 프로세스 관리에서 배우게 된다.)에 따라 프로세스가 선택 처리된다.

c. 수행상태에서 다시 준비상태로 가는 때는 현재 처리되고 있는 프로세스의 타임 퀀텀이 다 되었을 경우이다.

d. 수행상태에서 sleep상태로의 이동은 입력/출력 요청에 의해 이뤄진다. 하나의 프로세스가 수행상태에서 입력/출력이 요청되면 그 작업이 마쳐질 때까지 그 프로세스는 sleep상태로 잠시 이동되고 커널의 스케줄링 알고리즘에 따라 적절한 순위의 프로세스가 수행 상태로 이동되는 것이다.

e. sleep상태에서 준비상태로의 이동은 입력/출력이 끝났다는 신호에 의해 이루어진다.

f. 수행상태에서 종료상태로의 이동은 작업이 성공적으로 완료되었거나 혹은 에러가 발생하여 작업이 미리 종료되는 경우이다.

요점정리

 Process Life Cycle

1. 생성 - 디스크에서 메모리로 프로그램을 올리고 실행 준비를 하는 상태

2. 준비 - 순서에 맞춰 처리를 기다리는 상태

3. 수행 - 작업이 처리되고 있는 상태

4. sleep(=blocked) - 프로세스가 잠시 어떠한 조건에 의해 작업이 이뤄질 수 없는 상태로 그 조건이 해결되기를 기다리는 상태

5. 종료

안녕하세요? 허니입니다. 운영체제를 공부하는데 기본적인 용어와 개념들을 알아야 합니다. 많은 분들이 기본 개념들을 모르기 때문에 운영체제가 많이 어렵다라고 말씀들 하시는 것 같습니다. 그렇게 때문에 오늘 기본적으로 알아야 할 운영체제 개념들에 대해서 포스팅 해 보겠습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 OS를 전체적으로 이해하는 데 기본이 되는 몇 개의 개념들

OS를 전체적으로 이해하는 데 기본이 되는 몇 개의 개념들

 Kernel

커널은 컴퓨터 시스템의 전원을 처음 켰을 때 메모리로 올라와 시스템이 동작되는 동안 계속 머무르는 부분으로 OS에서 가장 기초적이고 핵심적인 기능을 담당한다. 커널을 통해 메모리, 파일, 주변장치 등과 같은 시스템을 구성하는 중요한 자원들을 관리할 뿐만 아니라 시간관리, 프로세스관리, CPU 스케줄링, 메모리관리, 입출력 제어 등과 같이 컴퓨터 운영에 필요한 핵심사항들을 처리한다. 우리는 서론에서 컴퓨터 시스템 구조를 공부해봤다. 하나의 프로그램을 실행시킬 때는 그림 9와 같은 컴퓨터 시스템 구조와는 또 다른 컴퓨터 시스템 내부구조를 그려낼 수 있다. 여기서 커널의 역할은 하드웨어에 두 사람 이상이 동일한 작업을 실행시켰을 때 중재자의 역할을 하고 또한 여러 사용자가 시스템을 동시에 사용할 때 각자가 독자적으로 작업할 수 있도록 영역을 확보해준다. 앞서 OS를 한 국가의 정부와 비교해 보았다. 그렇다면 커널은 정부의 대표인 공무원이라고 비교하면 적절할 듯 하다.

그림 9 커널 영역

그림에서 커널이 하드웨어를 둘러싸고 있는 것은 하드웨어를 제어하는 기능을 갖고 있기 때문이다.  또한 application과 커널 사이에 자리잡고 있는 Library는 사용자가 프로그램을 실행시킬 때 커널에게 응용프로그램을 이해시켜 프로그램이 수행될 수 있도록 기능하게 된다. 만약 Library가 존재하지 않는다면 프로그램마다 OS가 바뀌어야 한다. 다시 말해 하나의 프로그램에는 그 프로그램을 이해하도록 설계된 OS가 꼭 짝을 이뤄야 하는 것이다. 어떠한 시스템 내에서라도 Library를 동일하게 구성함으로 어떠한 OS 내에서도 응용프로그램은 동일한 기능을 수행할 수 있는 것이다.

 Interrupts

이 단어를 사전에서 찾아보면 가로막다. ‘중단하다’로 해석된다. 사무실에서 A 프로젝트 기획안을 작성하는 도중 전화가 걸려온다면 그는 분명 일을 잠깐 멈추고 전화를 받을 것이다. 전화용건을 해결하고 난 다음 다시 기획안 작성을 하게 될 것이다. 이렇듯 하나의 프로그램 수행 중 현재의 프로그램과 상관없는 사건이 발생한다면 어떨까? 이러한 사건이 생기면 인터럽트를 일단 걸어 수행중인 작업을 잠시 멈추고 새로 발생한 사건을 처리하게 된다.

인터럽트에는 하드웨어와, 소프트웨어 인터럽트가 있다. 우리가 앞으로 배우게 될 프로세스 수행의 결과로 발생하는 인터럽트는 소프트웨어 인터럽트이고 하드웨어 장치로부터 비동기적으로 발생하는 것은 하드웨어 인터럽트이다. 즉 프로세스 수행과 무관한 외부적 원인으로 인터럽트가 발생되는 것이 바로 하드웨어 인터럽트이다. 중요한 것은 인터럽트 서비스 루틴은 가능한 짧아야 한다는 것이다. 원래 수행 중이었던 작업을 두고 인터럽트 서비스를 길게 처리할 수는 없을 것이다. 제2, 제3의 인터럽트가 발생했을 경우 그것 역시 제 시간에 수행돼야 하기 때문이고 인터럽트 발생이전 수행 중이었던 프로그램 역시 계속 수행해야 하기 때문이다. 이러한 인터럽트를 해석하고 서비스 루틴을 수행하는 역할을 하는 것을 인터럽트 핸들러(interrupt handler) 라고 한다.

그림 10 인터럽트

그렇다면 어떤 경우에 인터럽트를 사용될까? 대표적인 예는 키보드의 경우를 생각해 볼 수 있다. 만일 인터럽트를 사용하지 않는다면, CPU는 아주 빈번히 키보드의 입력을 매번 확인을 해야 할 것이다. CPU가 키보드 입력을 확인하는 주기는 아주 짧은 반면에 사람이 키보드를 두드리는 속도는 매우 느리다면, CPU는 키보드의 입력이 없음에도 불구하고 확인을 할 것이다. 하지만 입력이 없을 때의 확인은 아주 불필요한 것이고 이러한 작업은 CPU의 입장에서는 귀중한 CPU 수행시간을 낭비하는 것이다. 이러한 점을 착안해서 인터럽트 방식이 고안된 것이다. 키보드는 사용자가 키보드에 입력을 하면 키보드는 이러한 사실을 CPU에게 알리고 CPU는 어떠한 키가 눌러졌는지를 감지하게 된다. 즉, 키보드의 입력이 없는 동안에 CPU는 많은 일을 할 수 있을 것이다.

 Trap

트랩은 간단하게 말해 커널 안으로 들어가 커널 서비스를 제공받기 위한 하나의 절차이다. 예를 들어 컴퓨터 시스템 사용자가 작업도중 시간을 알고 싶다는 요청을 하면 트랩을 통해 커널 안으로 요청이 들어가고 커널은 트랩을 통해 들어온 요청이 실행 가능한 것인지를 판단해 서비스를 제공하게 되는 것이다. 바로 사용자와 커널간에 의사소통을 해주는 아주 유용한 통역자인 셈이다. 트랩은 커널과 Library의 경계선상에서 기능을 수행하게 된다.

 System call

System call을 간략하게 정의하자면 커널에게 작업을 의뢰하는 것이다. 트랩에서 언급했듯 작업도중 시간을 알고 싶다는 사용자의 요청 하나가 바로 하나의 system call인 것이다. 한글프로그램상에서 저장된 파일을 불러오는 것, 새로운 문서를 작성해 파일명을 지정해 저장하는 것, 디렉터리상에서 파일이름을 삭제하는 것 바로 이러한 작업 모두가 System call을 통해 수행되는 것이다. 프로그램 수행 중에 System call을 호출하면 트랩은 OS에게 System call을 전달한다. 그리고 나면 커널은 System call이 어떤 처리를 원하는 것인가를 확인하고 그에 해당하는 서비스를 처리한다. System call을 커널, 트랩과 연관 지어 설명하자면, 우리가 동사무소에 어떤 업무 처리를 위해 찾아갔을 때 (주민등록 떼기, 전입, 전출 신고, 출생신고 등) 그 하나하나의 업무들은 바로 system call과 동등한 의미가 되는 것이다. 그리고 우리는 그 처리를 담당자에게 요구하기 위해 해당용지에 기재 사항들을 적게 되는데 이러한 과정은 트랩이 담당하는 것이고 담당공무원이 업무를 처리해 주는 것 그것은 바로 커널의 역할인 것이다.

그림 11 System Call

 DMA(direct memory access)

프로그램 처리 중 입력/출력 처리속도가 느린 것을 염두에 두고 고안해낸 방법이다. 바로 입력/출력이 동작할 때 CPU와는 관계없이 직접 DMA 컨트롤러가 메모리에 접근해 입력/출력을 처리하는 것이다. DMA로 인해 입력/출력 처리 중에도 CPU는 쉼 없이 다른 처리를 할 수 있는 것이다. DMA 처리과정을 살펴보면 먼저 CPU는 DMA컨트롤러에서 입력/출력 내용들을 카피할 것을 명령한다. DMA 처리과정에서 CPU의 역할은 이 한가지로 막을 내린다. DMA 컨트롤러는 메모리에 접근해 입력/출력 내용을 카피하게 되고 그 내용은 디스크에 저장되게 되는 것이다. 바로 입력/출력 시간 동안 CPU의 낭비를 막기 위해 프로그램 처리를 분업화해 CPU는 자신의 영역 업무 만에 매달릴 수 있게 한 것이 바로 DMA이다. 결국 DMA를 사용함으로써, CPU의 사용률을 올릴 수 있게 된다.

그림 12 DMA

 문맥전환(Context Switching)

문맥전환이란 CPU의 수행 내용이 어떠한 조건에 의해 바뀌는 것을 의미한다. 쉽게 표현한다면 옷을 갈아입는다고 말할 수 있을 것이다. 옷을 갈아입는 사람은 CPU가 되고 옷은 수행되는 내용을 뜻한다. 현재 수행 중이었던 프로세스가 어떠한 조건에 의해 잠시 수행이 멈춰지고 그 다음 프로세스가 수행됨을 말한다. 예를 들어 타임쉐어링처럼 하나의 프로그램이 CPU를 사용할 수 있는 시간을 고정시켜 제한된 시간을 하나의 작업이 다 쓰고 나면 다음작업을 수행하게 될 때 문맥전환이 일어나게 되는 것이다.

문맥교환이 일어나게 되는 조건들은 다음과 같다.

1. 타임 퀀텀이 다 된 경우, 하나의 CPU로 여러 작업들을 처리하게 되면 작업을 보다 빠르게 수행하기 위해 일정시간을 정해 놓고 그 시간 동안 작업이 완료되지 않았을 경우 다음 작업을 수행하게 된다. 바로 CPU의 수행작업이 바뀌게 되는 것이다.

2. 입력/출력이 발생되어 그 유휴 시간 동안 CPU가 다른 작업을 수행할 경우, 입력/출력은 CPU를 통해 이뤄지는 작업이 아니므로 CPU는 여유 시간 동안 다른 작업을 수행할 수 있는 것이다.

그림 13 문맥 전환 (Context Switching)

 PCB (Process Control Block)

프로세스가 수행되기 위해서는 프로세스만이 필요할까? 여러 프로세스들이 하나의 시스템 내에서 처리되기 위해선 그 프로세스의 정보가 유지되어야 한다. PCB에는 프로세스에 어떤 자원이 할당되어 있고 또 프로세스가 어떠한 상태에서 수행 중인가를 나타내는 일체의 관련정보가 수록되어 있다. 사람이란 존재 역시 그 실체만으로 자신을 표현할 수는 없는 것이다. 이름이 무엇인지, 나이가 얼마고 하는 일은 무엇인지 등과 같은, 그 사람을 표현해줄 수 있는 모든 정보가 따라다니기 마련이다. 다시 말해 문맥교환에 필요한 모든 정보가 PCB에 수록되어 있는 것이다. 커널은 각각의 프로세스에 대한 PCB를 갖고 있다. 그렇다면 PCB에는 어떤 정보들이 수록되어 있는가?

- 프로세스가 준비, 실행, 대기 등 현재 어떤 상태인가.

- 프로세스가 다음 어떤 명령을 처리하나.

- 프로세스가 CPU를 얼마나 사용했나.

- 먼저 처리되어야 할 프로세스는 어떤 것인가.

등 모든 정보가 꼼꼼히 PCB에 저장되어 있다. OS가 CPU를 다른 프로세스의 작업을 처리하고 이전 프로세스에게 돌아왔을 때 이러한 정보가 남아있지 않다면 CPU는 분명 당황해 할 것이다.

그림 14 PCB

요점정리

 OS를 이해하기 위한 기본개념

- Kernel

커널은 컴퓨터 시스템의 전원을 처음 켰을 때 메모리로 올라와 그 이후 항상 주기억장치에 머무르는 부분이다. OS와 상등한 개념을 가지고 있다.

- Interrupts

하나의 프로그램 수행 중 현재의 프로그램과 상관없는 사건이 발생한다면 어떨까......

이러한 사건이 생기면 인터럽트를 걸어 수행중인 작업을 잠시 멈추고

새로 발생한 사건을 처리하게 된다.

- Trap

트랩은 간단하게 말해 커널모드 안으로 들어가 커널 서비스를 제공받기 위한 하나의 절차이다.

- System call

System call을 간략하게 정의하자면 커널에게 작업을 의뢰하는 것이다.

- DMA (direct memory access)

바로 입력/출력이 동작할 때 CPU와는 관계없이 직접 DMA 컨트롤러가 메모리에 접근해 입력/출력을 처리하는 방법으로 입력/출력 처리 중에도 CPU는 쉼 없이 다른 처리를 할 수 있다.

- Context Switching

Context Switching이란 CPU의 수행 내용이 어떠한 조건에 의해 바뀌는 것을 의미한다.

- PCB (Process Control Block)

PCB에는 프로세스에 어떤 자원이 할당되어 있고 또 프로세스가 어떠한 상태에서 수행 중인가를 나타내는 일체의 프로세스 관련정보가 수록되어 있다.

안녕하세요? 허니데이즈입니다. 오늘은 지르콘 시스템콜이 뭐가 있는지 포스팅 하겠습니다.

지르콘 커널에서 사용되는 시스템콜은 현재까지 20여가지 기능을 하기 위한 세트로 정의되고 있으며 다음과 같다.

 Handles

handle_close - close a handle

handle_close_many - close several handles

handle_duplicate - create a duplicate handle (optionally with reduced rights)

handle_replace - create a new handle (optionally with reduced rights) and destroy the old one

Objects

object_get_child - find the child of an object by its koid

object_get_cookie - read an object cookie

object_get_info - obtain information about an object

object_get_property - read an object property

object_set_cookie - write an object cookie

object_set_property - modify an object property

object_signal - set or clear the user signals on an object

object_signal_peer - set or clear the user signals in the opposite end

object_wait_many - wait for signals on multiple objects

object_wait_one - wait for signals on one object

object_wait_async - asynchronous notifications on signal change

Threads

thread_create - create a new thread within a process

thread_exit - exit the current thread

thread_read_state - read register state from a thread

thread_start - cause a new thread to start executing

thread_write_state - modify register state of a thread

Processes

process_create - create a new process within a job

process_read_memory - read from a process's address space

process_start - cause a new process to start executing

process_write_memory - write to a process's address space

process_exit - exit the current process

Jobs

job_create - create a new job within a job

job_set_policy - modify policies for a job and its descendants

Tasks (Thread, Process, or Job)

task_bind_exception_port - attach an exception port to a task

task_kill - cause a task to stop running

task_resume - cause a suspended task to continue running

task_resume_from_exception - resume a task from a previously caught exception

task_suspend - cause a task to be suspended

Channels

channel_call - synchronously send a message and receive a reply

channel_create - create a new channel

channel_read - receive a message from a channel

channel_read_etc - receive a message from a channel with handle information

channel_write - write a message to a channel

Sockets

socket_create - create a new socket

socket_read - read data from a socket

socket_write - write data to a socket

Fifos

fifo_create - create a new fifo

fifo_read - read data from a fifo

fifo_write - write data to a fifo

Events and Event Pairs

event_create - create an event

eventpair_create - create a connected pair of events

Ports

port_create - create a port

port_queue - send a packet to a port

port_wait - wait for packets to arrive on a port

port_cancel - cancel notifications from async_wait

Futexes

futex_wait - wait on a futex

futex_wake - wake waiters on a futex

futex_requeue - wake some waiters and requeue other waiters

Virtual Memory Objects (VMOs)

vmo_create - create a new vmo

vmo_read - read from a vmo

vmo_write - write to a vmo

vmo_clone - clone a vmo

vmo_get_size - obtain the size of a vmo

vmo_set_size - adjust the size of a vmo

vmo_op_range - perform an operation on a range of a vmo

vmo_replace_as_executable - add execute rights to a vmo

Virtual Memory Address Regions (VMARs)

vmar_allocate - create a new child VMAR

vmar_map - map a VMO into a process

vmar_unmap - unmap a memory region from a process

vmar_protect - adjust memory access permissions

vmar_destroy - destroy a VMAR and all of its children

Cryptographically Secure RNG

cprng_draw

cprng_add_entropy

Time

nanosleep - sleep for some number of nanoseconds

clock_get - read a system clock

clock_get_monotonic - read the monotonic system clock

ticks_get - read high-precision timer ticks

ticks_per_second - read the number of high-precision timer ticks in a second

Timers

timer_create - create a timer object

timer_set - start a timer

timer_cancel - cancel a timer

Hypervisor guests

guest_create - create a hypervisor guest

guest_set_trap - set a trap in a hypervisor guest

Virtual CPUs

vcpu_create - create a virtual cpu

vcpu_resume - resume execution of a virtual cpu

vcpu_interrupt - raise an interrupt on a virtual cpu

vcpu_read_state - read state from a virtual cpu

vcpu_write_state - write state to a virtual cpu

Global system information

system_get_features - get hardware-specific features

system_get_num_cpus - get number of CPUs

system_get_physmem - get physical memory size

system_get_version - get version string

Logging

log_create - create a kernel managed log reader or writer

log_write - write log entry to log

log_read - read log entries from log

Multi-function

vmar_unmap_handle_close_thread_exit - three-in-one

futex_wake_handle_close_thread_exit - three-in-one

DDK

cache_flush - Flush CPU data and/or instruction caches

interrupt_ack - Acknowledge an interrupt object

interrupt_bind - Bind an interrupt object to a port

interrupt_create - Create a physical or virtual interrupt object

interrupt_destroy - Destroy an interrupt object

interrupt_trigger - Trigger a virtual interrupt object

interrupt_wait - Wait on an interrupt object

smc_call - Make an SMC call from user space

acpi_uefi_rsdp

ioports_request

framebuffer_set_range

vmo_create_contiguous

vmo_create_physical

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭! 

안녕하세요? 허니데이즈 블러그에 찾아주셔서 감사합니다. Fuchsia Friday에서 2018.7에 게시된 글을 읽고 그 내용을 공유하고자 포스팅합니다.

많은 사람들이 구글에서 퓨시아(Fuchsia)가 향후 5년 이내에 Android를 대체한다는 보고서를 보았고 독자 여러분 역시 뉴스를 통해 기사를 본적이 있을 겁니다. Google이 안드로이드가 가진 핵심 생태계를 어떻게 신속하게 대체할 수 있는지에 대한 많은 우려와 걱정이 공존하고 있습니다. 최근에는 퓨시아가 어디에 어떻게 쓰일지 많은 관심을 가지고 있으며 어떻게 구글이 안드로이드를 퓨시아로 생태계를 전환할 수 있는지 많은 사람들이 궁금해 하고 있습니다.

구글에서 최근 제시한 퓨시아 관련 보고서를 보면 조만간 퓨시아 장치 중 하나를 향후 3년 내 스마트 스피커를 볼 수 있을 것입니다. 이를 위해 Google은 퓨시아(Fuchsia)와 오늘날의 Google 홈에서 제공하는 플랫폼에 통합하는 작업에 어려움을 겪고 있습니다. 이 외에도 새로운 스마트 스피커를 구매할 가치가 있는 사람은 이미 가지고있는 장치, 특히 Android와 호환되는 장치와 상호 작용할 수 있어야 합니다. 그 중 일부는 블루투스와 같이 우리가 당연한 것으로 여기는 단순한 것들입니다. 구글은 이미 퓨시아와 안드로이드 기기간에 블루투스 연결이 작동하도록 자동화된 테스트를 이미 만들었습니다.

크롬캐스트(현재 오디오 전용)와 같은 일부 퓨시아(Fuchsia) 장치를 처리하여 기존 크롬캐스트 호환 음악, 팟 캐스트, 오디오북 앱과 호환될수 있도록 작업이 진행 중에 있습니다.

프로젝트 "가우스"가 곧 출시 될 퓨시아(Fuchsia)를 실행하는 제품인지는 분명하지 않지만 Google 홈의 복제본처럼 보일 수 있습니다. 이 장치는 더 중요하고 복잡한 장치로 이동하기 전에 현실 세계에서 OS의 생존 가능성을 입증하는데 도움이 될 것입니다.

그러나 이 전환과 관련하여 잠재적인 문제가 많습니다. 어느 누구도 새 Google 홈을 구입하지 않습니다. 이전 Google 홈이 하던 모든 작업만 수행 할 수 있는 새 홈은 전혀 볼 수없는 새로운 운영 체제용이기 때문입니다. Fuchsia의 첫 번째 장치가 잘 통합된다면 약 5년 후에 Android에서 Fuchsia로 운영체제가 바뀔 것입니다.

먼저, 앱을 가져올 수 있는지 여부에 대해 걱정할 필요가 없습니다. 구글은 이미 유튜브와 2017년 3월에 작업중인 구글 크롬 포트를 포함한 주요 제품에 네이티브 퓨시아 앱을 개발하고 있습니다. 아직 확인되지는 않았지만 Fuchsia는 안드로이드 런타임에 대한 지원을 받고있는 것으로 보이고, 안드로이드 런타임은 대부분의 안드로이드 앱이 퓨시아 폰에서 정상적으로 작동해야 함을 의미합니다.

그러나 운영체제를 전환해야 할 가능성이 여전히 염려되는 경우이를 명심해야 합니다. Fuchsia가 5년 계획을 갖고 있다면 Android에도 역시 5가지 계획이 있습니다. 안드로이드는 일반적으로 퓨시아가 의존하는 안정적인 네트워크 연결이 없는 10억 사용자에 대한 Google의 야심의 일부입니다. Fuchsia가 이러한 시장에 도달할 수 있는 방법을 찾지 않으면 안드로이드의 개발은 방해받지 않을 것입니다. 제 3의 제조사가 곧 모든 폰을 안드로이드 폰으로 만드는 일은 거의 없게 될 것입니다. 마지막 Android 기기가 만들어 지더라도 최소한 1년 또는 2년 동안 보안 업데이트로 지원해야 합니다.

확실히 전환은 완전히 완료되는데 수년이 걸릴 것입니다. Android에서 곧바로 전환하고 싶지 않은 경우 옵션을 사용할 수 있습니다. Fuchsia의 기본 응용 프로그램 프레임 워크로 Flutter를 사용하면 Android, iOS 용으로 만든 앱을 Fuchsia에서 쉽게 실행할 수있을뿐만 아니라 Fuchsia 용으로 만든 앱을 Android, iOS와의 호환성을 유지하도록 설계 할 수 있습니다. Fuchsia가 단순히 Android의 새 버전으로 판매 될 가능성이 항상 있음을 기억해야 합니다. 이 시점에서 아직 많이 모르는 부분이 있습니다.

우리는 몇 년 후에 일어날 일에 대해 이야기하고 있다는 것을 기억하는 것이 중요합니다. Google의 경우 변경 계획, 새로운 개발, 더 나은 전환 계획을 위한 충분한 시간입니다.

출처: https://9to5google.com/2018/07/27/fuchsia-friday-how-fuchsia-could-ease-into-the-google-ecosystem/

안녕하세요? 허니데이즈입니다. 오랜만에 포스팅 합니다. 그동안 회사에서 바쁜일이 있어서.ㅠㅠ 오늘은 핸들(Handles)에 대해서 이야기 해 보고자 합니다.

 개념

Handles은 사용자 모드에서 프로그램이 커널 객체를 참조할 수있게 해주는 커널 구조이다. Handle은 특정 커널 객체에 대한 세션이나 연결로 생각할 수 있다. 여러 프로세스가 서로 다른 Handle을 통해 동일한 객체에 동시에 접근하는 경우가 있다. 하지만 단일 Handle은 단일 프로세스에 바인딩되거나 커널에만 바인딩될 수 있다. 커널에 바인딩될 때 'in-transit'로 표현된다. 사용자 모드에서 Handle은 단순히 일부 시스템 호출에 의해 반환된 특정 번호이다. 전송 중이 아닌 핸들만 사용자 모드에서 볼 수 있다. Handle을 나타내는 정수는 해당 프로세스에 대해서만 의미가 있다. 다른 프로세스의 동일한 번호가 Handle에 맵핑되지 않거나 완전히 다른 커널 오브젝트를 가리키는 Handle에 맵핑 될 수 있다. Handle의 정수 값은 ZX_HANDLE_INVALID에 해당하는 값을 제외한 32비트인 숫자이다. 커널 모드의 경우 Handle은 세 개의 논리 필드를 포함하는 C++ 객체이다.

• A reference to a kernel object: 커널 객체에 대한 참조
• The rights to the kernel object: 커널 객체에 대한 권한
• The process it is bound to (or if it's bound to kernel): 바인딩된 프로세스

'rights'은 커널 객체의 어떤 작업이 허용되는지를 명시한다. 단일 프로세스가 다른 권한을 가진 동일한 커널 오브젝트에 대해 두 개의 서로 다른 Handle을 가질 수 있다.

 Handle 사용하기

새로운 커널 객체를 생성하고 Handle을 반환하는 많은 syscall이 존재한다. 몇 가지 예를 들면 다음과 같다.

• zx_event_create

• zx_process_create

• zx_thread_create

위 호출은 커널 객체와 이를 가리키는 첫 번째 Handle을 생성하게 된다. Handle은 syscall을 발행한 프로세스에 바인드되며 권한은 해당 유형의 커널 오브젝트에 대한 기본 권한이다. 같은 커널 객체를 가리키고 syscall을 실행한 동일한 프로세스에 바인딩된 Handle 사본을 만들 수있는 시스템 콜은 오직 하나뿐이다.

• zx_handle_duplicate

상응하는 Handle을 만들 수 있는 한 개의 시스템콜이 있다(권한이 적을 수 있음). 원래 Handle을 무효화 한다.

• zx_handle_replace

Handle을 파괴하는 시스템 호출이 있다.

• zx_handle_close

호출 프로세스에 바인딩 핸들을 받아 커널에 바인딩하는 두 개의 시스템 콜이 있다.(Handle을 전송 중입니다).

• zx_channel_write

• zx_socket_share

in-transit Handle을 사용하여 호출 프로세스에 바인딩하는 세 개의 syscall이 있다.

• zx_channel_read

• zx_channel_call

• zx_socket_accept

위의 채널과 소켓 syscalls는 한 프로세스에서 다른 프로세스로 Handle을 전송하는데 사용된다. 예를 들어 채널과 함께 두 개의 프로세스를 연결할 수 있다. 핸들을 전송하기 위해 타겟 프로세스는 zx_channel_write 또는 zx_channel_call을 호출하고 대상 프로세스는 동일한 채널에서 zx_channel_read를 호출한다. 마지막으로, 새 프로세스에 부트스트랩 Handle을 제공하는 단일 시스템콜이 있다. 즉, 다른 Handle을 요청하는데 사용할 수 있는 Handle이다.

• zx_process_start

부트 스트래핑 Handle은 전송 가능한 커널 객체일 수 있지만 가장 합리적인 경우는 채널의 한쪽 끝을 가리키는 것이므로 초기에 채널을 사용하여 새로운 프로세스에 추가 Handle을 보낼 수 있다.

 Garbage Collection

Handle이 유효하면 이를 가리키는 커널 오브젝트가 유효함을 보장한다. 이는 커널 객체가 참조 카운트되고 각 Handle이 커널 객체에 대한 참조를 보유하기 때문에 보장된다. 그 반대는 Handle이 종료되면 그 Handle이 종료된다는 의미가 아니다. 객체를 가리키는 다른 Handle이 있거나 커널 자체가 커널 객체에 대한 참조를 보유하고 있을 수 있다. 예를 들어 스레드에 대한 Handle로 스레드에 대한 마지막 Handle이 종료된다면 스레드가 종료되었음을 의미하지는 않는다. 커널 객체에 대한 마지막 참조가 해제되면 커널 객체가 파괴되거나 커널이 객체에 Garbage Collection을 표시한다. 객체는 현재 대기중인 작업 세트가 완료될 때 나중에 폐기된다.

Special Cases

Handle이 전송 중이고 쓰여진 채널이나 소켓이 종료되면 Handle이 닫히게 된다. 디버깅 세션에는 Handle에 대한 접근 권한을 얻기 위한 특별한 syscalls가 있을 수 있다.

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/handles.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭!