OS - OS가 할일, 컴퓨터 시스템구성

운영체제가 할 일

전체 컴퓨터 시스템은 크게 4가지로 나뉜다.

• 하드웨어
• 운영체제
• 응용프로그램
• 사용자

여기서 하드웨어는 주로 CPU, 입출력 장치(모니터, 키보드 등) 계산용 자원을 제공하는 매개체

응용프로그램은 사용자의 문제를 해결하기 위해 위의 자원을 사용한다.

 

그럼 운영체제는?

 

운영체제는 다양한 응용프로그램간의 하드웨어 사용을 제어하는 역할을 수행한다.

시스템 관점에서의 운영체제

컴퓨터의 입장에서 운영체제는 가장 하드웨어와 밀접한 관계를 가진 프로그램이다.

이러한 운영체제는 다양한 하드웨어 자원에 대한 관리를 수행한다.

 

그런데 다양한 응용프로그램들을 사용하게 되면서, 이들 하드웨어 자원에 대한 요청이 아주 많아 질 때가 있다.

운영체제는 자원 관리자로서 효율적으로 어느요청에 어떤 자원을 할당할지를 선정하게 된다.

 

즉, 자원할당자이자 제어 프로그램으로서의 역할을 수행한다.

이러한 운영체제는 항상 실행되어 있는 프로그램인 커널과 시스템 프로그램, 응용 프로그램으로 구성되어 있다.

컴퓨터 시스템 구성

현대의 컴퓨터는 하나 이상의 cpu, 그밖의 구성요소 그리고 공유 메모리사이에 버스를통해 연결된 장치 컨트롤러로 구성 되어 있다.

 

여기서 말하는 장치 컨트롤러는 오디오 장치나 디스크 등의 장치를 담당한다.

 

일부 장치 컨트롤러는 로컬 버퍼 스토리지와 특수 목적 레지스터 집합을 관리하는 역할을 수행한다.

 

이러한 장치 컨트롤러를 관리하기 위해 운영체제는 각 장치 컨트롤러 별 장치 드라이버가 있다.

 

장치 드라이버는 운영체제별로 일관된 인터페이스를 제공하는 역할을 수행한다.

 

CPU와 각 장치 컨트롤러는 병렬로 실행되어 공유 메모리를 가지고 경쟁하게 되는데

이 때 메모리 컨트롤러가 메모리에 대한 접근을 동기화 시켜준다.

인터럽트

보통의 컴퓨터에서 입출력 작업을 수행한다고 가정한다면

1. 장치 드라이버가 장치 컨트롤러의 레지스터에 적절한 값을 저장한다.
2. 장치 컨트롤러가 이러한 레지스터를 읽어들인 후 어떤일을 수행할지 결정한다.
3. 장치 컨트롤러가 작동하고 읽어들인 데이터를 로컬 버퍼 스토리지에 저장한다.
4. 장치 컨트롤러는 데이터 적재가 완료되었다는 신호를 장치 드라이버에게 보낸다.
5. 장치 드라이버는 입력이 완료되었다고 스토리지의 데이터 시작주소를 반환한다.

위와 같은 수행을 하게 된다.

운영체제가 장치 컨트롤러를 관리하기 위한 장치 드라이버가 있다고 위에서 언급하였다.

이러한 장치 드라이버는 입력값 읽기 요청의 경우 읽어 들인 데이터의 시작주소를 반환하면서

장치 컨트롤러가 가지고 있던 제어를 다시 운영체제에게 반납한다.

 

위의 상황에서는 하드웨어 장비를 직접 제어하는

즉, 하드웨어와 가까운 개체인 장치 컨트롤러가 운영체제의 인터페이스인 장치 드라이버에게 어떻게 신호를 주는건가?

 

이 때 발생하는것이 인터럽트이다.

 

하드웨어 장치들은 각 장치에 대한 운영체제가 갖고 있는 드라이버에 의해 관리된다.

 

이 때 위에서 언급했던 버스를 통해 CPU에게 신호를 보내어 인터럽트를 발생시킨다.

 

일단 CPU 입장에서는 인터럽트가 발생하게 되면

하던일을 잠깐 멈추고 (다음에 시작 할 주소를 프로그램 카운터에 적재),

해당 인터럽트에 대한 정보를 조사하여 어떤 인터럽트인지 확인 후

 

적절한 서비스 루틴의 시작주소로 제어를 이동시켜서 헨들러를 수행한다.

서비스 루틴 내 핸들러의 동작이 완료되면 CPU는 다시 멈추었던 시점(카운터에서 들여다 봐서)에서 원래 하던일을 수행하게 된다.

 

그런데 인터럽트는 매우 빈번하게 발생 할 수 있기 때문에

적절한 색인 과정을 거쳐 서비스 루틴의 시작주소가 담긴 테이블인 인터럽트 벡터를 사용하는 운영체제가 있다.

 

그럼 CPU입장에서는 언제 인터럽트를 감지하는 걸까?

 

CPU에는 인터럽트를 감지하는 선이 있다. 이 선을 인터럽트 요청 라인이라고 부른다.

CPU는 자신이 처리하고 있는 명령어 하나를 처리하고 나면 해당 선을 검사하게 된다.

주기적으로 검사하다가, 어떤 장치 컨트롤러로 부터 인터럽트가 발생한다면 인터럽트 요청라인을 통해 인터럽트 색인번호를 함께 전송한다.

CPU는 이를 읽어들여서 인터럽트 벡터에서 서비스 루틴의 시작주소를 찾고,

제어를 넘겨서 적절한 인터럽트 서비스 루틴의 헨들러를 수행 후

인터럽트를 수행 하기 전 주소로 이동하여 CPU가 원래 처리하고 있던 명령어 처리를 수행한다.

 

이러한 장치 컨트롤러에서 인터럽트 요청라인으로 인터럽트 색인번호를 전달하는것 까지가 raise(발생) 이라고 하고

CPU는 이것을 catch(포착)하여 적절한 서비스 루틴 헨들러로 현재 운영체제의 CPU 제어를 dispatch(넘기고) 넘기고 헨들러는 작동 후 해당 인터럽트를 clear(지운다) 한다.

 

여기까지가 기본적인 장치 컨트롤러와 이를 관리하는 장치드라이버간의 인터럽트 발생 로직이다.

하지만 여기서 몇 가지를 추가적으로 고려해야 한다.

1. 현재 CPU가 수행하고 있는 일이 더 중요하다면 인터럽트 처리를 오히려 미뤄야 한다.
2. 인터럽트 벡터의 색인된 번호들 보다 더 많은 양의 헨들러가 있을 수 있다.

2번사항을 먼저 고려해보자

 

기본적으로 운영체제 별로 상이하지만 인터럽트 벡터를 사용한다고 하면

기존의 CPU에게 인터럽트를 발생시키기 위해 연결되있는 선인 인터럽트 요청 라인은 크게 두개의 종류가 있다.

 

하나는 마스크 불가능 인터럽트 요청라인 과 마스키 가능한 인터럽트 요청라인이다.

마스크 불가능한 인터럽트는 기본적으로 어떤 서비스가 수행될지 마스킹 되어있는 인터럽트들이다.

 

이들을 제외한 장치인터럽트를 포함한 인터럽트는 나머지 마스킹 가능한 인터럽트 벡터에 색인된다.

하지만 장치의 개수가 인터럽트 내 마스크 가능한 번호 개수보다 더 많아지게 된다.

 

이럴 때 사용하는 기법 중 하나인 인터럽트 체인 기법이 있다.

기존의 벡터내에 각 원소(서비스 루틴 헨들러 시작주소)들은 색인번호와 함께 단 하나씩 매칭되었는데

그것이 아니라, 각 백터 내 헨들러 리스트가 생기게 된다.

 

따라서 더 많은 양의 장치에 대한 헨들러 시작주소를 벡터 내에 색인하더라도 문제가 없게된다.

 

다만, 리스트가 들어가기 때문에 용량에 한계를 극복했어도, 어떤 적절한 헨들러를 찾을 때 까지 검색해야 하는 오버헤드는 발생하게 된다.

 

추가적으로 위의 고려사항 중 1번을 해결하는 방안으로서 인터럽트들 사이에 우선순위를 고려하면 된다.

결론

운영체제는 다양한 하드웨어 자원을 관리하고 응용프로그램들 간에 효율적으로 할당하는 소위말해 정부 역할을 수행

 

각각의 장치는 장치 컨트롤러가 있고, 운영체제 단에서 관리하는 인터페이스로 장치 드라이버가 존재함

 

각 장치 드라이버에 인터럽트가 발생하면 하던일 멈추고 어떤 인터럽트 서비스 루틴 헨들러를 호출할지 벡터에서 찾고 제어를 넘겨서 처리 후 원래 하던일로 돌아감

 

벡터의 색인번호 크기를 극복하기 위해서 체이닝 기법을 사용하나 이는 크기의 한계극복과 검색시간에서의 트레이드 오프 관계임