Operating System - Ch.04 Thread & Concurrency

본 글은 Operating System Concepts 10판을 기준으로 작성되었습니다...!

 

 

 

Process란 "실행 중"인 program을 의미한다

Program은 디스크에 그냥 있는 상태.

작성된 프로그램이 메모리 공간을 할당받고 실행중인 상태.

 

음... Process는 좀 무겁네... 

address space도 크고,, PCB 크기도 크고... OS 자원도 너무 많이 먹어... 

많은 데이터와 많은 저장공간이 필요하네...

또 여러 프로세스 돌리면서 스케듈링할 때 생기는 오버헤드도 있고...

프로세스끼리의 소통이 커널을 통해 이루어지니까 좀 비싸다...

어떻게 해결 안되나?

 

하나의 단일 process 안에서 여러 execution path를 만들면 가볍게 동작하지 않을까?

그리하여...

 

★Thread 등장★

 

와대박

 

스레드는 CPU Utilization (CPU 활용)의 기본 단위로, thread ID, PC(program counter), a register set 그리고 stack으로 구성되어있다. 동일한 프로세스 내의 다른 스레드들과 code, data, 파일 열기나 신호들과 같은 운영체제 자원들을 공유한다. 만약 프소세스가 여러 스레드를 가진다면, 같은 시간에 하나 이상의 일을 할 수 있는 것이다. 

 

Single-threaded and multithreaded processes

 

오늘날의 컴퓨터들은 모두 멀티스레드로 동작한다. 책에서는 다음과 같은 멀티스레드 어플리케이션의 예는 다음과 같다.

 

1. 여러 이미지를로부터 썸네일을 만드는 프로그램은 썸네일을 만들기 위해 각 이미지별로 스레드를 나눠서 사용한다.

2. 웹 브라우저는 이미지를 띄울 디스플레이를 위한 스레드, 그리고 네트워크로부터 정보를 받아오는 스레드가 동시에 존재한다.

3. 워드프로세스는 그래픽을 디스플레이에 표시할 스레드, 유저로부터 키 입력을 받기 위한 스레드, 그리고 문법이나 오타 체크를 위한 스레드가 동시에 존재한다.

 

 

멀티스레딩의 장점

1. Responsiveness

  상호작용하는 어플리케이션에서 멀티스레딩을 사용하는 경우 특정 부분에서 긴 연산이나 멈춤이 있어도 사용자와 계속 상호작용이 가능하다. 이러한 점은 user interface를 설계하는 데에 특히 유용하다. 

2. Resource sharing

  프로세스들은 오직 shared memory나 message passing을 통해 자원을 공유 가능하다. 이는 프로그래머가 명시적으로 구현해줘야 하는 방법들이다. 하지만 스레드는 메모리와 프로세스 자원들을 공유한다.

3. Economy

  프로세스가 만들어질 때 메모리와 자원을 할당하는 것은 코스트가 비싸다. 반면 스레드는 프로세스의 자원을 공유하기 때문에 스레드를 새로 만들거나 context-switch하는 데에 더 경제적이다. 

4. Scalability

  스레드들이 다른 코어에서 병렬적으로 돌아갈 수 있다. 덕분에 multiprocessor 구조에서 더욱 좋다.

 

---

 

 싱글코어와 멀티코어

  4개의 스레드를 가지로 어플리케이션을 돌려보자.

 

Concurrent execution on a single-core system (싱글코어)

  하나의 cpu에 하나의 코어만 있을 때, 동일한 때에 parerell하게 스레드를 실행할 수 없으므로 번갈아가면서 수행

시간이 지나면서 컴퓨터의 성능을 올리기 위해 멀티CPU 시스템이 등장하는데, 바로 멀티코어의 등장이다.

 

Parallel execution on a multicore system (멀티코어)

  멀티코어 같은 경우에는 코어 별로 pararell하게 스레드를 실행한다. 성능이 코어의 수만큼 n배가 될 것이다.

 

 

Data vs Task parallellism

 

  data parallelism같은 경우에는 슈퍼컴퓨터 같은 경우에 사용한다...

 

Data parallelism은 같은 데이터의 부분집합들을 여러 연산 코어에 분배하고 각 코어에서 같은 동작을 수행하는 데에 초점을 맞춘 것.

Task rarallelism은 데이터가 아니라 스레드를 여러 연산 코어에 분배하는 것이다. 각 스레드는 각자의 연산을 처리한다. 이 때 다른 스레드가 같은 데이터 혹은 다른 데이터에 연산을 진행할 수 있다.

 

 

Parallel Programming libraries

 병렬 프로그래밍을 위한 라이브러리가 존재하는데 다음은 유명한 병렬 프로그래밍 라이브러리다.

 - Pthread (POSIX threads)

 - OpenMP (Open Multi-Processing)

 - Open MPI (Message Passing Interface)

 - SIMD

 - GPGPU

---

 

그럼 스레드는 어떻게 구현할까? 스레드를 구현하는 방법을 알아보자.

처음에 스레드라는 개념이 나왔을 때 (LWP의 개념일 시절...), 기존의 UNIX시스템 같은 경우에는 multiprocess, time sharing 이 두 가지 철학이 근간이었다. 근데 스레드 괜찮을 것 같은데?

커널에서 이런 스레드라는 개념을 집어 넣는 것이 쉬울까? 아니 어려워...

그래서 개발자들이 라이브러리 형태로 개발을 하기 시작한다. 커널은 그런거 몰라

그것이 바로 User threads 라고 하는 것이다.

그럼 커널에 스레드 들어가면? Kernel Thread, 최신 운영체제는 대부분 커널에서 스레드 관련 기능을 제공한다.

 

당연히 커널에서 스레드 관리하는 것이 신뢰성 있고 좋다.

다만 운영체제 입장에서는 User-level thread가 오버헤드가 적다. 

 

Multithreading Models 여러가지 멀티스레딩 모델들.

 

Many to One

커널 스레드는 하나, 유저 스레드 여러개.

 

One to One

커널 스레드 하나에 유저 스레드 하나가 연결된 형태

윈도우가 이런 형태이고, 윈도우는 멀티스레딩이 기본이다.

 

Many to Many (ㅡ:ㅡ)

커널 스레드 n개, 유저 스레드 n개가 있고 이것들이 One to One 처럼 1대1로 매칭되지는 않는 형태

동적으로 각 스레드들이 서로 동작한다.

리눅스가 이런 형태다.

 

Two-level

Many to Many + One to One

 

스레드라는 것이 유닉스가 생길 때는 없었고, 따라서 유닉스의 철학과는 다른 부분이 여럿 있었다.

따라서 유닉스가 스레드를 채택하면서 생긴 여러 문제들이 있었는데,

 

1. Semantics of fork() and exec() system call

fork()나 exex()같은 시스템 콜에서 생기는 문제 (가장 critical)

예를들어 5개의 스레드가 있고, 5번 스레드를 fork()했는데, 이 때 5번 스레드의 복제본을 새로 만들어서 할 것이냐, 아니면 원래 fork()의 매커니즘대로 스레드 다섯개짜리 형태를 두개 만들어서 할거냐... 고민이 되는 것이다...

이건 사실 아직 표준으로도 채택되지 않았다. 니맘대로해. 그래서 운영체제별로 다르다.

그래서 개발자들이 이걸 딱 보면 혼선이 올 수밖에 없다. 그래서 어떻게 했느냐.

암묵적인 룰로 멀티스레딩 안에서 만들어진 녀석들에서는 fork() 쓰지 말자고 정함.

2. Thread cancellation

  그런게 있구나

3. Signal handling

  그런게 있구나

4. Thread pools

  그런게 있구나

5. Thread specific data

  그런게 있구나

 

Pthreads : POSIX threads, POSIX 규정을 따르는 스레드다.

 

MS/DOS는 단일 프로세스

초기 유닉스는 멀티 프로세스

초기 리눅스는 clone이라는 시스템 콜로 스레드 관리했는데 커널 차원에서 관리가 잘 안됬음.

리눅스 2.6부터는 Many to Many 모델로 갔다.

자바는 VM process 하나당 여러 스레드. VM간의 스레드끼리 소통하고 싶다면 VM끼리 연결 해줘야됨