OS_운영체제 카테고리의 PE Series는
2021.10.20 - [학부공부/OS_운영체제] - 00. 운영체제 STUDY 시작
00. 운영체제 STUDY 시작
안녕하세요! 제가 티스토리 페이지를 만든 후 처음으로 작성하는 글입니다... 복학하기 전 개인적인 공부를 정리하자는 취지로 시작하는 글이라 가독성이 떨어지고 부족한 부분이 있을 수 있으
ku320121.tistory.com
포스팅에서 소개한 text book의 연습문제를 풀이한 것을 정리한 것입니다. 해설을 참고하지 않았기 때문에 풀이에 오류가 있을 수 있습니다. 또한 운영체제 교과목 내용을 벗어나는 내용과 사견이 풀이에 포함되어 있을 수 있습니다.
4.1. Provide three programming examples in which multithreading provides better performance than a single-threaded solution.
Web server, Web client, Game.
Web server에서 single thread를 사용한다는 것은 결국 user request마다 process를 생성하여 처리한다는 것이다. Process간 context switching overhead가 thread switching overhead가 크므로 multithreading이 유리하다.
Web client program도 마찬가지로 cooperative process로 지원한다면 process간 context switching overhead가 존재한다. 뿐만 아니라 process간 message passing IPC를 사용한다면 shared memory 방식이 용이한 process 내부 thread간 communication에 비해 cost가 많이 든다. Multi core를 지원하는 최근 CPU HW환경에서는 더욱 multi control flow를 가질 수 있는 multithreading이 유리하다.
Game program의 경우도 대규모 행렬 연산, user 입력 처리, 화질 설정 등을 위한 성능 monitering, user간 채팅 등을 위해 각각 thread가 존재한다면 여러 개의 control flow를 통해 여러 개의 core에서 하나의 process를 실행할 수 있다는 점에서 유리하다.
4.2. Using Amdahl’s Law, calculate the speedup gain of an application that has a 60 percent parallel component for (a) two processing cores and (b) four processing cores.
4.3. Does the multithreaded web server described in Section 4.1 exhibit task or data parallelism?
4.1절 web server에서 제공하는 multithreading은 data parallelism이다.
해당 예시에서 thread는 각 client의 요청을 listen하는 동일한 기능을 수행하는 thread이기 때문에 data parallelism이다. 하지만 요청을 listen하는 것에서 나아가 database에서 search하는 등 listen과 다른 연산을 수행한다면 이는 task parallelism이 된다. 따라서 실제 web server는 task와 data parallelism을 동시에 취하는 program을 사용할 것이다.
4.4 What are two differences between user-level threads and kernel-level threads? Under what circumstances is one type better than the other?
Thread를 지원하는 주체와 multiprocessor 환경에서 thread 할당 여부에 차이가 있다.
User thread는 user level 라이브러리를 통해 구현되고 kernel thread는 OS에서 thread를 지원하여 thread 생성과 scheduling을 한다. User thread는 하나의 thread가 system call등에 의해 block된다면 동일 process 내의 다른 thread도 block된다. 이는 kernel이 여러 개의 user thread를 하나의 process로 간주하기 때문이다. Kernel thread는 block이 되어도 kernel이 다른 thread를 실행하여 전체적인 thread blocking이 없고 multicore환경에서 kernel이 여러 개의 thread를 각각 할당할 수 있다는 장점이 있다. 즉, kernel thread를 통해 실제 HW core에 scheduling이 가능하다는 의미이다.
User thread는 특정 process와 관련이 있지만 kernel thread는 하나 이상의 process와 관계를 가질 수 있다. User thread가 1개의 kernel thread에 mapping되기 때문에 user thread의 수는 kernel thread의 수보다 같거나 많다.
User thread는 user level 라이브러리에서 구현되어 있기 때문에 kernel thread에 비해 더 자유롭게 생성할 수 있다.
4.5 Describe the actions taken by a kernel to context-switch between kernel level threads.
Thread control block switching을 제공해주어야 한다.
Thread control block은 PC, register set, stack등의 정보를 포함한다. Ready 상태로 전환되는 thread에 대한 정보는 store하고 run 상태로 전환되는 thread의 정보는 load하여야 한다. 또한 multithread 중 하나의 thread가 exit()하는 경우라면 resource 해제여부를 결정해야 한다. 해당 thread가 exit()되더라도 다른 thread가 해당 thread에 할당된 resource를 계속 사용할 수 있기 때문이다.
4.6 What resources are used when a thread is created? How do they differ from those used when a process is created?
Thread control block(Register set, Stack, PC 등).
Thread는 process의 code와 data section을 공유하기 때문에 PCB보다 작은 resource를 사용하면 된다. Thread를 process보다 더 작은 execution unit으로 제공하기 위해 제공되는 thread control block은 thread별 control flow를 위한 PC, register set, stack과 thread scheduling을 위한 정보를 포함한다.
4.7 Assume that an operating system maps user-level threads to the kernel using the many-to-many model and that the mapping is done through LWPs. Furthermore, the system allows developers to create real-time threads for use in real-time systems. Is it necessary to bind a real-time thread to an LWP? Explain.
Real-time system을 위한 real-time thread는 LWP에 binding되어야 한다.
Many to many model의 경우, real-time thread를 만들면 LWP가 binding되어 있어야 kernel thread에 곧바로 mapping될 수 있다. 즉, real-time thread가 실행될 수 있더라도 LWP에 mapping되어 있지 않다면 LWP에 binding될 때까지 기다려야한다. 따라서 binding을 해놓으면 응답시간을 줄일 수 있다.
다만, real-time system이 dynamic scheduling tick(scheduling time slice)을 제공한다면 real-time으로 LWP binding이 되지 않아도 LWP가 kernel에서 빠르게 복귀하게 하여 real-time을 보장해주도록 만들 수 있다. 그럼에도 불구하고 binding을 기다리기 위해 늘어나는 응답시간을 단축시키진 못한다는 점에서 근본적인 해결책은 아니다. 따라서 real-time system을 위한 real-time thread는 LWP에 binding되어야 한다.
댓글