2.2: Program execution시스템은 프로그램을 기억 장치에 적재하여 실행할 수 있어야 하고, 프로그램은 정상적 혹은 비정상적으로 프로그램의 실행을 끝낼 수 있다.사용자 레벨의 프로그램은 CPU 시간을 적절히 배정하는데서 신뢰성이 떨어진다.: I/O operations수행중인 프로그램이 입출력을 요구할 수 있는데, 이러한 입출력은 파일 혹은 입출력 장치가 지정될 수 있다. 특정 장치들에 대해서는 특수한 기능들(테이프 구동기 되감기, CRT화면지움)이 요구 될 수 있는데 사용자 프로그램은 직접적으로 입출력 동작을 수행할 수 없기 때문에 운영체제가 입출력 동작을 해주기 위한 방법을 제공해야 한다.사용자 레벨의 프로그램에서는 접근해야할 때 접근하는 것과 사용하지 않을 때에도 접근하는 것에 대해 신뢰성이 떨어진다.: File-system manipulation파일 시스템은 특히 중요한 분야로 프로그램은 분명히 파일을 읽고 기록해야 되며, 또한 이름에 의하여 파일을 생성하고 삭제할 필요가 있다.사용자 레벨의 프로그램은 사용자가 올바른 파일에 접근하는지, 파일은 배정해선 안되는 블록에 배정하는 것에 대해 신뢰성이 떨어진다.: Communications한 프로세스가 다른 프로세스와 정보를 교환하는 방법은 여러 가지가 있다. 첫째로 동일한 컴퓨터에서 수행되고 있는 프로세스들 사이에서 일어나고, 두 번째는 컴퓨터 네트워크에 의하여 함께 묶여 있는 다른 컴퓨터 시스템 상에서 수행되는 프로세스들 사이에서 일어난다. 통신은 공유메모리를 통해서 구현될 수도 있고, 비교적 사용도가 낮은 메시지 전달 방법에 의하여 구현될 수 있는데, 정보의 단위인 패킷들이 운영체제에 의해 프로세스들 사이를 이동하게 된다.: Error detection운영체제는 모든 가능한 오류들을 항상 탐지할 수 있어야 한다. 오류는 CPU, 기억장치 하드웨어, 입출력 장치, 또는 사용자 프로그램에서 일어날 수 있다. 운영체제는 올바르고 일관성 있는 계산을 보장하기 위해 오류의 각 종류에 대해서 적당한 조치를 취해야 한다.다수의 사용자가 있는 시스템에서는 사용자들 사이에 컴퓨터 자원을 공유함으로써 효율성을 높일 수 있다.2.3: a. 레지스터에 있는 파라미터를 보낸다.b. 레지스터가 파라미터 블록의 시작주소를 보낸다.c. 파라미터는 프로그램에 의해 스택으로 밀어 넣어지게 되고 운영체제에 의해 스택에서 빠져 나올 수 있다.2.5: Creating and deleting files(파일의 생성과 제거): Creating and deleting directories(디렉토리 생성과 제거): Supporting primitives for manipulating files and directories(파일과 디렉토리 조작을 위한 프리미티브의 제공): Mapping files onto secondary storage(보조 기억 장치에 있는 파일로의 사상(mapping)): Backing up files on stable (nonvolatile) storage media(안전한(비휘발성) 저장 매체에 파일을 저장)2.9: 매커니즘은 어떻게 할 것인가를 결정 하는 것이고, 반대로 정책은 무엇을 할 것인가를 결정하는 것이다. 정책(policy)과 매커니즘(mechanism)의 분리는 융통성을 위해 매우 중요하며, 정책은 장소에서 장소로, 시간에서 시간으로 시간을 바꾸는 것과 같은 것이다. 최악의 경우 정책에서의 각 변경은 기본 메커니즘의 변경을 요구하게 된다. 정책 변경은 시스템의 매개변수만을 재정의 하도록 요구하며 일반적인 매커니즘이 보다 바람직하다. 정책결정은 모든 자원 할당과 스케줄링 문제에 중요하며 자원 할당의 여부를 결정할 필요가 있을 때마다 정책 결정을 해야 한다.2.14: 가상 기계(virtual-machine)는 몇 가지의 장점들이 있다. 우선 가상 기계 환경에서는 여러 가지 시스템 자원에 대한 완전한 보호가 이루어진다. 각 가상기계는 다른 모든 가상 기계로부터 완전히 분리되어 보안의 문제점은 없지만 반면 자원을 직접 공유할 수도 없다. 또한 가상기계 시스템은 운영체제 연구와 개발에 완벽한 매체로서 사용될 수 있다. 운영체제는 조금만 변경 할 경우 다른 부분에 보이지 않는 결함을 초래 할 수 있지만 가상 기계 시스템은 이러한 문제점을 대부분 제거할 수 있다. 각 시스템 프로그래머는 물리적인 기계 대신에 자신에게 주어진 가상 기계상에서 시스템 개발을 할 수 있다. 따라서 시스템 개발을 위해 정규 시스템 동작을 중단할 필요가 거의 없다.
1.1.a: time-sharing 환경에서 각 사용자들은 LAN으로 연결되어 있어 한 사용자가 다른 사용자의 파일을 액세스 하는 것이 가능하다. 접속을 하는 사용자는 접속 대상 컴퓨터에서 파일 사용에 대한 권한을 얻을 수 있다면 대상 컴퓨터의 파일을 가져오는 것이 가능하다. 또한 이 과정에서 바이러스와 같은 프로그램들이 번질 수 있다.multiprogramming 환경에서는 한 프로그램의 버그가 다른 프로그램에 영향을 미칠 수 있다. 이는 경미한 영향일 수도 있지만 운영체제에 할당된 메모리 내용의 변경과 같은 커다란 영향을 미칠 수도 있다.1.1.b: 우리가 전용컴퓨터에서 갖는 동일한 수준의 보안을 time-shared machine 에서는 시스템을 여러 사람이 네트워크에 연결되어 있어 확신하기 어렵다. dedicated machine은 외부의 침입을 쉽게 알아 방어할 수 있으나 time-shared는 시스템전체의 보안문제가 해결되어야만 여러 보안 문제가 해결될 수 있기 때문이다. 또한 네트워크에 연결되어 있어 dedicated machine의 경우보다 많은 사용자들에게 노출된다. 그동안 설계된 수많은 보안설계가 다른 사람들에 의해 뚫렸던 것으로 볼 때 time-shared machine의 보안이 외부의 침입을 보다 더 잘 파악할 수 있는 dedicated machine만큼의 보안이 보장된다고 이야기하기는 어렵다.1.7: client-server와 peer-to-peer모델은 client-server가 client와 server로 확실히 구분되는데 반해 peer-to-peer는 그렇지 않다는 점에서 구분된다. client-server에서는 client가 server에게 서비스를 요청하지만 peer-to-peer는 각각이 서로 서버가 되기도 하고 클라이언트가 되기도 하므로 서로에게 서비스를 제공하기도 하고 요청하기도 한다.1.10: interrupt는 하드웨어와 관련한 시스템 안의 흐름의 변화이다. interrupt handler는 interrupt에서 야기된 문제를 다루기 위해 호출된다. 그리고 control이 interrupt된 상황과 명령으로 돌아간다. trap은 소프트웨어와 관련된 interrupt이다. interrupt는 device polling의 필요성을 제거하기 위해 I/O의 완성을 알리려고 사용된다. trap은 operating system routine을 호출하거나 산술에러를 잡기위해 사용된다.1.13: cache는 둘 혹은 그 이상의 components가 서로 데이터를 교환하려할 때 유용하다. cache는 component 사이에 중간속도의 버퍼를 제공함으로써 transfer의 문제를 해결한다. 만약에 빠른 장치가 cache에서 원하는 자료를 찾으면 느린 장치를 기다릴 필요가 없다. 만약 component가 data값 변화가 있고 datum 또한 cache에 있으면 cache는 업데이트 된다. 이것은 하나 이상의 multiprocessor system에서 datum에 접근할 때 특히 문제가 된다. 컴포넌트는 cache와 component가 같은 저장력을 가지고 cache가 감당할 수 있을 때 같은 사이즈의 cache에 의해 제거된다. 왜냐하면 빠른 기억장치는 더 비싸기 때문이다.1.17.a: Batch는 사용자가 명령을 입력하는 즉시 처리되는 것이 아니라 변동사항을 일정정도 모아두었다가 한꺼번에 처리하는 방식이다. 이 방법은 데이터 발생으로부터 처리까지의 시간이 길어지므로 시급한 업무에는 적합하지 않다. Batch는 자료를 일, 주, 월 단위 등 일정기간 단위로 모으거나 일정 지역 단위로 모았다가 한꺼번에 처리하므로 관리자의 입장에서 관리가 쉬워지고 컴퓨터를 사용함에 있어 계획을 세울 여유가 생기고 컴퓨터를 능률적으로 사용할 수 있다. 반면에 응답시간이 길어지므로 사용자 입장에서는 불편하다.1.17.b: Interactive는 시스템과 사용자 사이의 직접적 통신을 제공하는 시스템이다. 이 시스템은 키보드나 마우스로 사용자가 프로그램에 명령을 직접 주기 때문에 결과를 얻을 수 있는 응답시간이 매우 빠르다. 컴퓨터와 사용자가 단말기 등을 통해 대화하듯이 명령과 결과를 서로 주고받으며 작접을 처리해 나가는 이 시스템은 time-shared 시스템에서 사용되는 방식으로 오늘날 대부분의 컴퓨터가 사용하고 있으며 사용자가 자신이 명령한 작업을 느끼면서 진행할 수 있으므로 오류의 가능성이 적다.1.17.c: time sharing은 한 컴퓨터를 여러 사용자가 동시에 사용할 때 사용자들이 해당 컴퓨터의 CPU의 resource를 나누어 사용하는 것이다. 이를 통해서 사용자들은 각각 별개의 단말기를 통해 동시에 독립적으로 일할 수 있게 된다.1.17.d: real time은 컴퓨터가 사용자가 입력한 데이터를 가능한 빠르게 처리하여 결과를 즉시 내보내는 방식이다. 이 시스템은 컴퓨터가 항상 입력을 감시하다가 입력발생 즉시 처리하여야 하므로 사용자가 실시간으로 결과를 볼 수 있지만 시스템에 장애가 발생할 경우 장애 시간 중 발생한 입력은 전혀 처리하지 못하므로 문제가 발생할 수 있다. 따라서 이 처리방식을 제공하는 컴퓨터는 처리속도가 매우 빠르고 고장이 생겨도 수행을 계속할 수 있는 장치가 마련되어야 한다.
자바 배포를 위한JSmooth 활용- 목차 -1. 서론22. 본론 22.1 JSmooth22.1.1 JSmooth 소개22.1.2 JSmooth 필요성32.2 JSmooth 활용32.2.1 실행 파일 만들기32.3 프로그램 배포72.3.1 InstallFactory를 활용한 배포73. 결론84. 참고자료91. 서론오픈 소스로 개발된 Eclipse)는 그동안 울트라 에디터나 에디터 플러스)를 이용하여 코딩하고 컴파일, 빌드 등 모든 과정을 복잡하게 수행하던 Java 개발자들을 편리하게 해주었다. 개발자들은 Eclipse를 통해 자동 컴파일 기능 및 에러의 발생 유무와 해결방법까지 알 수 있게 되었다.그러나 Eclipse를 활용하여 개발이 쉬워지긴 했지만 Java로 만든 프로그램의 배포는 여전히 어렵다. Visual C++이 손쉽게 확장자가 exe인 파일을 만들 수 있는 것에 비해 Eclipse는 class파일이나 jar 파일)을 만들어내기 때문에 쉽게 실행시킬 수 없다. 또한 이러한 파일의 배포에 성공하였다 하더라도 JRE)이 갖추어지지 않은 컴퓨터에서는 실행이 되지 않기 때문에 여러 모로 Java를 이용해 만든 프로그램의 배포에는 어려움을 겪을 수밖에 없다.현재 자바 파일을 배포본으로 만들어 주는 프로그램에는 여러 가지가 있으나 JSmooth다 그 중에서도 가장 쓰기 쉽고 편하다고 판단되어 본 보고서에서는 JSmooth를 Java로 만든 프로그램의 배포에 활용하는 방법을 알아보려고 한다.이에 자바 배포를 위한 JSmooth가 무엇이며 어떻게 사용하고, 이를 이용하여 만든 실행 파일을 JRE가 설치되지 않은 컴퓨터에서 실행되게 하기 위해 InstallFactory를 활용하는 방법에 대해 알아보려고 한다.2. 본론2.1 JSmooth2.1.1 JSmooth 소개JSmooth는 Rodrigo Reyes 라는 개발자가 Java만을 이용하여 만든 소프트웨어로 소스포지(http://www.sourceforge.net/)에 등록된 무료 소프트웨어이다.현재 0.9.9 버전이 나와있으며 한글화된 소프트웨어 또한 인터넷을 통해 쉽게 구할 수 있다.자바로 만든 프로그램의 배포를 위해서 Installanywhere 나 InstallShield 와 같은 프로그램을 사용할 수도 있지만 이들은 JSmooth에 비해 설정이 매우 까다롭다. JSmooth를 이용하면 Eclipse를 통해 만든 확장자가 jar인 파일을 가지고 실행 파일인 exe파일로 손쉽게 만들 수 있다. 위 두 프로그램이 설정할 것이 많고 설치파일 제작에 실패하는 경우도 있는 것과 달리 JSmooth는 설정이 매우 간단하여 자바 개발자들이 배포에 유용하게 사용하고 있다.JSmooth는 http://jsmooth.sourceforge.net/index.php에서 다운로드 할 수 있다.2.1.2 JSmooth 필요성Eclipse를 이용해 개발한 자바 프로그램은 실행 파일로 만들 수 없다. 이 때문에 C 개발자들이 Visual C++이나 기타 프로그램을 이용하여 손쉽게 실행 파일을 만들고 이를 배포본으로 만드는 것에 비해 배포에 앞서 실행 파일도 만들어 낼 수 없는 곤란을 겪었다. Java를 이용하여 프로그램을 개발할 경우 확장자가 jar 인 파일을 만들 수 있는데 Java를 아는 사람에게는 이 파일을 건네주면 이를 사용할 수 있지만 일반 사람들에게 프로그램을 배포하기 위해서는 일단 exe 파일로 만드는 것이 우선이다.JSmooth는 이러한 곤란을 해소하기 위해 만들어진 것으로 Java 개발자가 만든 jar 파일을 exe 파일로 바꾸어주는 역할을 한다.이에 자신의 프로그램을 배포하고자 하는 Java 개발자들에게 있어서 JSmooth는 필수적이라고 말할 수 있는 프로그램으로 그 필요성은 매우 크다.2.2 JSmooth 활용2.2.1 실행 파일 만들기JSmooth를 이용하여 jar 파일을 exe 파일로 만드는 경우를 설명하고자 한다.본 예시에 사용된 소스는 ‘객체지향 프로그래밍’ 수업 교재로 사용하고 있는 ‘완벽 자바 프로그래밍’ 393 페이지의 ‘이미지 뷰어 만들기’의 소스를 이용하였다.개발자가 Eclipse를 이용하여 코드를 모두 작성하였다면 JSmooth를 사용하기 위하여 우선 이를 jar 파일로 내보내줘야 한다.위 그림처럼 java 파일에 마우스 우클릭 후 Export 를 클릭한다.왼쪽 그림과 같은 창이 뜨면JAR file을 선택한 후Browse를 클릭하여 붉은 상자 안에서와 같이 JAR file이 내보내질 경로를 입력한다. 이 때 jar 파일의 이름을 설정해주지 않으면 파일 이름이 설정되지 않은 채 ‘.jar’ 파일이 생성된다.JAR file 이 만들어진 것을 확인하고 JSmooth를 실행시킨다. JSmooth 프로그램에서의 진행순서는 위 그림에서처럼 Skeleton -> Executable -> Application -> Compile 순으로 진행한다.우선 Skeleton 을 선택하여 우측 화면 Skeleton Selection에서 Windows Wrapper를 선택한다.다음 Executable 을 선택하고 우측 화면에서 위 그림 오른쪽 붉은 상자를 클릭하여 exe 파일이 만들어질 경로와 파일명을 입력한다. 이 때 '파일명.exe' 라고 확장자까지 확실히 입력시켜 주어야 한다. 여기서는 ImageViewer.exe 라고 입력하였다. 이 때 만들어질 exe 파일의 경로를 jar 파일이 포함된 경로와 동일하게 하지 않으면 나중에 InstallFactory를 이용한 배포에 어려움을 겪을 수 있으므로 동일한 폴더로 설정해준다.Application을 선택하여 우측에서 우선 Classpath에서 이전에 만들어둔 jar 파일을 선택한다. 그 다음 Application Settings에서 Main Class를 등록한다.여기서는 미리 만들어둔 ImageViewer.jar 파일을 등록한 후 Main Class에는 소스코드대로 Ex10_26_MyImageLoader를 등록하였다.마지막으로 위 메뉴에서 그림과 같은 아이콘을 클릭하면 컴파일이 진행되고 설정해둔 경로에 설정해둔 파일명으로 된 실행파일이 생성됨을 확인 할 수 있다.본 보고서에서는 ImageViewer.exe 파일이 생성하였고 이를 실행해보면 Eclipse 상에서 Java Application 을 이용하여 실행해 본 것과 같은 결과를 얻을 수 있음을 알 수 있다.2.3 프로그램 배포2.3.1 InstallFactory를 활용한 배포위에서 만든 ImageViewer.exe는 개발자의 컴퓨터에서는 실행이 가능하다. 그러나 JSmooth를 이용하여 만든 이 실행 파일은 Eclipse에서 Export 시킨 ImageViewer.jar 파일이 함께 있지 않다면 실행이 불가능하다. 또한 jar 파일을 함께 제공한다 하더라도 JRE가 갖추어지지 않은 컴퓨터라면 역시 실행이 불가능하다.따라서 배포 시에는 우선 배포할 컴퓨터에 JRE를 설치해주어야 하고 그 후에 exe 파일과 jar 파일을 제공하여야 한다.본 보고서에서는 InstallFactory를 이용하여 exe 파일과 jar 파일, 그리고 JRE를 묶어서 실행파일로 만들어 배포하는 방법을 소개하고자 한다.우선 InstallFactory를 실행한다. (InstallFactory는 http://file.naver.com/view.php?fnum= 28516에서 다운로드 할 수 있다.)우선 위 ‘만들기’버튼을 클릭 후 프로젝트의 이름을 설정한다. 그 다음 타이틀 에서는 프로그램의 타이틀을, 소스폴더에는 exe 파일과 jar 파일, jre-1_5_0_10-windows -i586-p.exe 파일이 모두 포함된 폴더를 설정한다. (jre-1_5_0_10- windows-i586-p.exe는 "Java 2 Runtime Environment Standard Edition, 즉 JRE로 http://file.na ver.com/view.php?fnum=130576에서 다운로드 할 수 있다.) 또한 기본 설치 폴더와 설치 파일이 만들어질 폴더, 이름 등을 설정한다.실행탭을 클릭하여 설치시 실행할 사용자 설치프로그램 을 체크 후 프로그램에 jre-1_5_0_10-window s-i586-p.exe 파일을 등록한다. 그리고 실행 완료 후 삭제를 체크한다.마지막으로 우측 상단에 있는 설치화일 만들기를 클릭하면 인스톨 파일이 만들어진다.만들어진 인스톨 파일을 실행하게 되면 설치가 완료된 후 JRE 설치 파일이 자동으로 실행된다. 순서에 따라 JRE를 설치하게 되면 JRE 설치 파일은 자동으로 삭제되고 exe 파일과 jar 파일만 남게 된다. 그리고 exe 파일을 실행시키면 성공적으로 실행이 된다. 즉 배포가 성공적으로 이루어진다.
3.0 Java에서 try{...}, catch{...}를 설명하시오.try{// 예외를 발생시킬 수 있는 코드}catch(발생할 수 있는 예외){// 발생한 예외를 처리하기 위한 코드}try{...}, catch{...}는 예외처리 구문이다.try블록에는 예외를 발생시킬 수 있을만한 코드가 들어간다. 파일 입출력이나 네트워크로 데이터 전송 등 비교적 예외상황이 발생할 확률이 높은 코드를 try/catch 문으로 처리하면 좋다. 예를 들어 다음과 같은 코드가 있을 때public class Exception {public static void main(String[] args){try{int a = 0;int num = 1000 / a;System.out.println(num);}catch(Exception e){System.out.println("0으로 나눌수 없습니다");}}}try 문 안에서 예외가 발생했을 시 catch 에 있는 System.out.println... 라인이 실행되는 것이다. 물론 예외가 발생하지 않았을 경우 catch 구문은 실행되지 않는다.참고로 try, catch 구문 아래에 finally{...} 구문을 추가하면 예외 발생여부와 관계없이 그 문이 반드시 실행된다.3.1 short-term, medium term, long term 스케쥴링 간의 차이를 설명하시오.1) 단기 스케쥴러 (Short-term scheduler)실행준비 상태에 있는 프로세스들 중 다음에 CPU에 할당하여 실행할 프로세스를 결정한다. 가장 빈번하게 동작한다.2) 중기 스케쥴러 (medium-term scheduler)장기 스케쥴러보다 더 빈번히 동작한다. 시분할 시스템에서는 프로세스를 메모리에서 디스크로 옮겨 당분간 실행되지 못하도록 하는 경우가 있다. 이것은 다중 프로그래밍의 정도를 조절하여 프로세스 혼합을 향상시키거나 메모리 요구사항을 충족시키기 위함이다. 이를 담당하는 스케쥴러가 중기 스케쥴러이다.3) 장기 스케쥴러 (long-term scheduler)한 번에 병행으로 수행할 수 있는 작업의 수가 제한되어 있으므로 주기억 장치에 위치시키지 못한 프로세스는 디스크에 유지되는 작업풀(job pool)에 유지된다. 장기 스케쥴러는 작업풀에서 프로세스 실행을 위해 주기억 장치에 위치시킬 다음 작업을 결정한다. 프로세스가 완료 되어 시스템을 떠날 때에만 새로운 프로세스를 생성하기 위해 호출하므로 실행 빈도수가 적다3.2 커널에서 프로세스 문맥 교환의 과정을 설명하시오.: context-switching은 CPU를 한 프로세스에서 다른 프로세스로 넘기는 작업이다.(1) 프로세스가 커널이나 수행 중인 다른 프로세스에 의해 생성되면 적재 메모리 영역등의 최소 필요자원 확보와 커널 내의 프로세스 제어 블록 등을 초기화하는 과정이 신규과정(2) 위 과정이 완료되면 프로세스 제어 블록은 준비 리스트에 삽입되어 중앙처리기 스케줄러로부터 CPU 할당을 대기함(3) CPU를 할당 받으면 프로세스는 실행 상태가 되어 사용자 모드 또는 커널 모드에서 실행됨(4) 프로세스 실행중 주어진 타임 슬라이스가 소진되면 스케줄러는 해당 프로세스로부터 CPU를 회수하여 다른 프로세스에 할당함(5) 이때, CPU를 회수당하는 프로세스는 프로세스의 수행이 일시 정지되는 것이므로 추후의 실행을 위하여 모든 필요 문맥(Context)를 저장하여 추후 실행 속개시 모든 값을 복원해야 함 (context switching)
5.1 CPU-bound 프로그램으로부터 I/O-bound 프로그램을 구분하는 스케줄러는 왜 중요한가?- 프로그램을 실행하면 I/O와 CPU를 사용한다. 즉 컴퓨터의 작업을 처리하는 시스템에는 하나의 CPU에서 실행하는 작업과 여러 개의 입출력작업을 갖는다. CPU 스케줄링에서는 프로세스의 점유 정도가 중요하기 때문에 I/O-bound 프로그램과 CPU-bound 프로그램을 구분하는 것은 각각 두 프로그램이 작업을 끝마쳤는지 여부에 따라 프로그램을 처리하고 두 부분의 작업량이 적당해야 하기 때문에 중요하다.- I/O-bound 프로그램과 CPU-bound 프로그램은 각각 따로 실행되는데 I/O-bound 프로그램은 CPU를 잠깐씩 사용하며 I/O를 많이 사용하고 CPU-bound 프로그램은 I/O를 사용은 하나 많지 않고 CPU를 한 번에 오래 사용하는 프로그램이다. 만일 CPU-bound 프로그램에서 I/O-bound 프로그램을 구분하지 못하면, convoy effect가 발생하기 때문에 구분하는 것이 중요하다.(I/O-bound 프로그램을 우선으로 한다.) ; CPU에서 작업을 처리하는동안 작업이 끝날 때까지 다른 프로세서들은 그들의 입출력 작업을 끝마치고 레디 큐로 이동하여 기다린다. 이렇게 레디 큐에서 기다리는 프로세서들은 작업을 수행하지 않고 있어서 매우 한가하다. 하지만 여기서 앞의 작업의 양이 많으면 바로뒤의 작업에 악 영향을 끼치는 효과(convoy effect)가 발생할 수 있어서 효율적이지 못하다5.4 1/1000초 단위로 주어진 CPU burst 길이와 함께 주어진 다음 프로세스를 보자.프로세스들은 P1, P1, P2, P3, P4, P5에 시간 0에 도착한다.a. 네 가지의 스케줄링 알고리즘을 이용하는 프로세스의 실행을 설명하는 Gantt chart를 그려라. FCFS, SJF, nonpreemptive priortiry(priority number가 작을수록 우선순위가 높다.), 그리고 RR(단위= 1)- FCFSP1P2P3P4P50 10 11 13 14 19- SJFP2P4P3P5P10 1 2 4 9 19- nonpreemptive priorityP2P5P1P3P40 1 6 16 18 19- RR(quantum=1)P1P2P3P4P5P1P3P5P1P5P1P5P1P5P10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 19b. 각각의 스케줄링 알고리즘에서 각각의 턴어라운드 시간은?P1P2P3P4P5①FCFS1011131419②SJF191429③Priority16118196④RR1927414c. 각각의 스케줄링 알고리즘에서 각각의 waiting time은?P1P2P3P4P5①FCFS010111314②SJF90214③Priority6016181④RR91539d. 어떤 알고리즘 결과의 waiting time의 평균이 가장 작은가?- FCFS : (0+10+11+13+14)/5 = 9.6- SJF : (9+0+2+1+4)/5 = 3.2- Nonpreemptive priority : (6+0+16+18+1)/5 = 8.2- RR : (9+1+5+3+9)/5 = 5.4->> waiting time의 평균이 가장 작은 것은 SJF이다.5.5 어떤 스케줄링 알고리즘에서 starvation이 나타날 수 있는가?a. First-come, first-served- 들어온 순서대로 실행되기 때문에 언젠가는 반드시 실행된다.b. Shortest job first- 어떤 프로그램보다 실행시간이 짧은 프로그램이 계속 들어온다면 그 프로그램은 영원히 실행될 수 없다.c. Round robin- 프로그램에 주어진 시간이 정해져 있기 때문에 starvation이 일어나지 않는다.d. Priority- 어떤 프로그램보다 우선순위가 높은 프로그램이 지속적으로 들어온다면 그 프로그램은 영원히 실행될 수 없다.5.7 시스템이 10개의 I/O-bound 업무와 한 개의 CPU-bound업무를 수행한다고 생각하자. I/O-bound 업무는 CPU computing 매 millisecond마다 한번씩 I/O 수행을 하고, 각각의 I/O 수행은 수행완성까지 10 millisecond가 걸린다고 가정해보자. 또한, context-switching overhead도 0.1 millisecond이며, 모든 프로세스들이 long-running 업무를 수행한다. 주어진 시간들을 기준으로 RR알고리즘 사용 시 CPU utilization은 얼마인가?