실버벨의 Stack Overflow

# SUBSTR (대상문자열, 시작위치, 길이)

 -> 대상문자열을 시작위치 부터 길이만큼 짜르기 

ex>

# INSTR(대상문자열, 타겟문자열, 시작위치, 횟수)

 -> 타겟문자열이 시작위치에서 몇 번째에 있는지 위치 반환

ex> STR = '방그리는 오늘도 눈부시다'

ps. 시작위치는 1부터 시작한다.

# 혼합형 예제

# ERROR : ORA-00918 : 열의 정의가 애매합니다.

# 원인 : 조회시에 같은 이름의 Column이 있고, 조회(select)시에 어떤 값을 사용할 지 결정할 수 없어 나는 오류.

# 해결방법

1) ALIAS를 사용하여 이름을 구분지어 중복되는 컬럼 값이 없게 한다.

2) 중복되는 컬럼 제거

Sample.

참고 ))

https://nolboo.kim/blog/2013/10/06/github-for-beginner/

** 뮤텍스란(Mutex)? **

“Mutual Exclusion 으로 상호배제라고도 한다. Critical Section을 가진 쓰레드들의 Runnig Time이 서로 겹치지 않게 각각 단독으로 실행되게 하는 기술입니다. 다중 프로세스들의 공유 리소스에 대한 접근을 조율하기 위해 locking과 unlocking을 사용합니다.

즉, 쉽게 말하면 뮤텍스 객체를 두 쓰레드가 동시에 사용할 수 없다는 의미입니다.

** 세마포어란?(Semaphore) **

세마포어는 운영체제 또는 커널의 한 지정된 저장장치 내 값으로서, 각 프로세스는 이를 확인하고 변경할 수 있습니다. 확인되는 세마포어의 값에 따라, 그 프로세스가 즉시 자원을 사용할 수 있거나, 또는 이미 다른 프로세스에 의해 사용 중이라는 사실을 알게 되면 재시도하기 전에 일정 시간을 기다려야만 합니다. 세마포어는 이진수 (0 또는 1)를 사용하거나, 또는 추가적인 값을 가질 수도 있습니다. 세마포어를 사용하는 프로세스는 그 값을 확인하고, 자원을 사용하는 동안에는 그 값을 변경함으로써 다른 세마포어 사용자들이 기다리도록 해야합니다.

*** 뮤텍스와 세마포어의 차이점 ***

1) Semaphore는 Mutex가 될 수 있지만 Mutex는 Semaphore가 될 수 없습니다.

(Mutex 는 상태가 0, 1 두 개 뿐인 binary Semaphore)

2) Mutex의 경우 Mutex를 소유하고 있는 쓰레드가 이 Mutex를 해제할 수 있습니다. 하지만 Semaphore의 경우 이러한 Semaphore를 소유하지 않는 쓰레드가 Semaphore를 해제할 수 있습니다.

3) Semaphore는 시스템 범위에 걸쳐있고 파일시스템상의 파일 형태로 존재합니다. 반면 Mutex는 프로세스 범위를 가지며 프로세스가 종료될 때 자동으로 Clean up된다.

★★★

가장 큰 차이점은 관리하는 동기화 대상이 갯수입니다. Mutex는 동기화 대상이 오직 하나뿐일 때,

 Semaphore는 동기화 대상이 하나 이상일 때 사용합니다.

★★★

[출처]: http://jwprogramming.tistory.com/13

#6-4. Process Synchoronization
: 프로세스 동기화에서 생기는 문제점 3가지를 알아보도록 하겠습니다.

* Bounded-Buffer Problem
: 버퍼의 크기가 유한

# 상황 설명
- Circular buffer 형태로 되어있다.
- 여러개의 Producer(생산자) 프로세스와
- 여러개의 Consumer(소비자) 프로세스가 있다.

# 역할
 - Producer : 공유버퍼에다가 데이터를 하나 만들어서 집어넣는역할.
 - Consumer : 데이터를 꺼내가는 역할
(원형 버퍼의 그림을 보면 주황색 색칠 부분은 producer가 데이터를 넣은것이고, 색칠 안된 동그라미는 consumer가 데이터를 쓴것.

???)

여기서 Synchronization과 관련해서 어떤문제들이 발생할까?

1) 공유 버퍼이기 때문에 생산자가 둘이 동시에 도착해서 동시에 데이터를 만들어 집어 넣으면 동기화 문제가 발생.
=> 공유 버퍼에 lock을 걸어서 동기화문제를 해결해야 한다.

2)공유 버퍼이기 때문에 소비자가 둘이 동시에 도착해서 동시에 데이터를 가져가면 동기화 문제가 발생.
=> 역시 공유 버퍼에 lock을 걸어서 동기화문제를 해결하도록 한다.

3) 버퍼가 유한(Bounded) 하기 때문에 생기는 문제
: 즉, 버퍼가 찼는데, 생산자(producer)가 도착하는 경우, 또는 버퍼가 비었는데 소비자(consumer)가 도착하는 경우.
=> producer는 버퍼가 가득 찼는지, consumer는 버퍼가 비었는지 체크 해줘야 한다.

----------------------------------------------------------
!!!)

 Semapore 를 이용해서 해결해야할 문제가 2가지가 있다.

1) 동시에 공유 버퍼에 접근하는것을 막기 위해서 lock을 걸었다가 푸는 작업.

2) 버퍼가 가득 차거나, 비었을 때를 알수 있게 counting Semapore가 필요하다.
----------------------------------------------------------

# 세마포어로 구현한 생산자, 소비자 문제

* Readers - Writers Problem

# 상황 설명

- 프로세스는 2종류(읽는 P, 쓰는 P)
- 공유 데이터 : DB

Sol)

Reader는 동시접근이 가능하게 하고,

Writer는 동시접근이 불가능하게 해야한다.

# 세마포어를 통한 문제 해결 코드

# Reader 부분 설명

1) 노란색 부분인 if(readcount == 1) P(db); 을 보면 1일때에만 db(스몰 db)로 lock을 걸어주게 되고, 1이 아니면 이미 lock이 걸려 있기 때문에 DB에 바로 들어갈 수 있다.

2) But, 여기서 readcount도 공유 변수 이므로 동시에 접근할 경우 동기화 문제가 발생할 수 있다. 그래서 mutex변수를 이용하여 readcount에 접근하는 부분에도 lock과 unlock을 걸어주도록 한다.

!!!)

그렇지만 Writer의 Starvation 현상이 발생한다.

readcount가 0이 되어야 V(db)로 lock이 풀리는데,

Reader가 너무 많아 지면 Writer는 Starvation 현상이 발생하게 된다.

* Dining - Philosopheres Problem (식사하는 철학자 문제)
:  2가지 업무가 있다. (생각하는 업무, 밥을 먹는 업무)

!!!)

노란색 코드 때문에 Deadlock이 발생할 수 있는 위험한 코드이다.

why))

 eat()에 들어가기 전에 모든 철학자가 P(chopstick[i])코드 때문에 자신의 왼쪽 젓가락을 들고 안놓게 된다... 그렇게 될 경우 아무것도 진행이 될 수 없는 Deadlock 현상이 발생하게 된다.

 그럼 어떻게 해결을 해야 할까?

# 식사하는 철학자문제를 세마포어로 해결한 코드

# 변수 설명
- semaphore self : 각각의 5명의 철학자가 젓가락 2개를 잡을수 있어서 젓가락 잡는 권한을 줄것이나 말것인가를 정하는 변수.

 ex>
 - self[1] = 0; // 1번 철학자는 젓가락 잡기 불가능.
 - self[3] = 1; // 3번 철학자는 젓가락 잡기 가능.

- mutex : state변수에 접근에 lock/unlock 을 위한 변수.

- test 함수 : 젓가락 잡을수 있는 권한이 있나?
 즉, 왼쪽 철학자랑 오른쪽 철학자가 먹고 있지 않고, 내가 hungry인 상태일때, 젓가락 잡을수 있는 권한 획득.

* 세마포어의 문제점

=> 세마 포어를 개발자가 잘 지키면 프로그램이 제대로 돌아가겠지만, 제대로 했는지 확인이 힘들다....

* Moniter
: 공유데이터를 접근하기 위해서는 모니터라고 정의된 내부에 프로시저를 통해서만 내부의 공유 데이터에 접근할수 있게 만들어 놓는것. 그리고 모니터가 원천적으로 내부에 프로시저가 동시에 여러개가 실행되지 않도록 만드는것.(=> 이렇게 되면 lock을 걸 필요가 없다.)

(프로그래밍 언어 차원에서 동기화 문제를 해결을하는 High-level Synchronization construct)

semaphore의 lock & unlock기능은 해결!!

???)
자원의 개수를 어떻게 셀까?

# 함수 설명

- wait() : 자원이 없으면 기다리게 하는 함수
- signal() : 접근을 다하고 빠져나갈 때 호출(invoke)하는 함수

* 모니터 내부 형태

* 모니터로 convert한 Bounded-Buffer & Dining - Philosopheres Problem
: 세마포어처럼 lock을 걸 필요가 없다.
(모니터 안에서 하나의 프로세스만 실행되기 때문에!!)

#6-3. Process Synchronization

cf > 추상 자료형 : 논리적으로 정의하는것이지, 실제로 컴퓨터에서 어떻게 구현되는지는 별개의 문제.

* Semapores
: 추상 자료형

# semapore 자료형은 p연산과 v연산이 존재하게 된다.

---------------------------------------------------------
???) Semapore라는것을 왜 사용 하는가?

공유 자원을 획득하고 반환하는것을 세마포어가 처리해준다!

p 연산 : 공유데이터를 획득하는 과정
v 연산 : 다 사용하고 나서 반납하는 과정.

=> p연산을 하면 lock을 거는 과정이고, v연산은 lock을 푸는 과정이다.
---------------------------------------------------------

# 세마포어 값은 Integer(정수) 값을 가지는데, 자원의 갯수를 의미 한다.

cf> p연산과 v연산은 atomic 하게 연산이 된다고 가정한다!

* Critical Section of n Processes
: critical section 문제에다가 semapore를 사용해보자.

# mutex 변수를 1로 놓고,

critical section에 들어가야 할때(lock을 걸때)에는 p연산을 해주고,

  critical section을 나올때(lock을 풀때)에는 v연산을 해준다.

=> 이렇게 되면 critical section문제가 자연스럽게 해결이 된다.

=> 즉, 세마포어를 통해서 프로그래밍을 해주면 개발자는 훨씬 간단한 프로그래밍을 할수 있다. (6-2에서 나왔던 알고리즘을 고려하지 않아도 된다)

But.. 누군가 critical section에 들어가 있다면 p연산에서 while문을 돌면서  기다리기 때문에 busy-waiting (= spin lock)이 해결 되지는 않는다...

cf> Block & Wakeup 방식 (=sleep lock)
: 누군가가 critical section에 있다면, 쓸데없이 while문을 도는(spin)하는 것이 아니라 blocked 상태에서 기다리는 방법!

* Block / Wakeup Implementation
: 세마포어 변수를 획득하지 못한 프로세스는 block상태에 두는것.

# 구체적으로 어떻게 구현되는지 살펴 봅시다!

# p 와 v에 들어있는 s는 세마포어 변수

v. p연산 : 자원을 획득하는 과정
 - 자원에 여분이 있다면 획득!
 - 자원에 여분이 없다면 block();

v. v연산 : 자원반납하고, 자원을 기다리면서 혹시 잠들어 있는 자원이 있다면 그 자원을 깨워주는 연산

???)

v연산에서 if(S.value <= ) { wakeup(P); }

를 보면 자원을 내놓았는(S.value++) 데에도 불구하고

S.value가 음수 인 경우는 block()된것이 많다는것이다.

그래서 wakeup() 으로 깨워준다.
 

=> busy waiting 방식과는 조금 다르다.
: busy waiting 방식에서는 단순히 자원의 갯수를 세는 경우였는데, block-wakeup방식은 조금 다르다. 
 block-wakeup방식에서는 단순히 세는것이 아니라 깨워야할 누군가가 있는지를 확인하기 위해 사용된다.

* 어떤 방법이 더 좋은 방법 일까?

# block / wakeup 하는 방법에도 overhead가 있다. critical section이 짧은 경우에는 busy - waiting도 괜찮다.

* Two Types of Semaphores
: 세마포어의 두가지 타입

* Deadlock and Starvation
: 세마포어를 사용할때 주의해야 원치 않는 문제

1) Deadlock :
: 상대방이 가진것을 기다리면서 자기것은 내놓지 않고, 서로 영원히 기다리는것을 DEADLOCK이라고 한다.

ex> 세마포어 S 와 Q, 두개가 있는데, 세마포어 두개를 모두 획득해야지만, 일을할수 있는 그런 환경.

P0순서에서 S를 획득했다. 그런다음에 P1에 차례가 넘어갔다.
P1순서애서 Q를 획득했다.

=> P0와 P1은 서로를 무한히 기다리게 된다.

=> 해결방법 : 자원을 획득하는 순서를 똑같이 맞춰주자. 즉, 모든 프로세스가 S먼저 획득하고 Q를 획득하게끔 해준다.

2) Starvation
: 특정프로세스만 자원을 받고, 나머지 프로세스는 무한히 기다리는 것.

* 동기화 기본 코드

# 그림설명 : 임의의 프로세스의 code 소개.

 cf> critical section : 공유데이터를 접근하는 코드

     remainder section : 공유데이터를 접근하지 않음

     (entry, exit) section : lock을 거는 행위

     ???) 여러 프로세스가 동시에 critical section에 들어가는 것을 막는다. (이것이 동기화 개념!)

* Critical Section문제를 풀기 위해서 만족해야 할 조건 

: 크게 3가지가 있다.

# Mutual Exclusion : (entry, exit) section 부분.

  Progress : 코드를 잘 못 짜면 이러한 문제 발생.

  Bounded Waiting : 기다리는 시간이 유한해야 된다.(즉, starvation이 생기지 않아야 한다.)

  ex> cirtical section에 들어가고 싶은 프로세스가 3개가 있는데 2개만 들락날락 거리고

        나머지 한개는 마냥 기다리는 상황이 생겼을때 Bounded Waiting조건을 만족하지 못한다.

=> 이 3가지 조건을 만족하면서 lock을 잘 걸었다가 푸는 그런 알고리즘들을 알아보도록 하자!

* Algorithm 1 

: turn 교대가 포인트!!

cf>

1) P0를 위한 코드

2) P1를 위한 코드

# turn이 0이면 0번 프로세스, 1이면 1번 프로세스!

# 위에 코드는 1번 조건인 Mutual Exclusion은 만족한다 (P0의 경우, while (turn != 0), turn = 1로 인해서)

But, 2번 조건인 Progress는 만족 x.

why??))

코드를 보면 한 프로세스가 critical 세션에서 나와야 지만 턴이 상대 차례로 변하게 된다. 근데 이런 프로세스의 critical section 빈도가 다를수 있다. 

극단적으로, P0는 critical section에 여러번 들어가고 싶은데, p1은 한번만 들어가고 안들어가도 된다. 이런 경우엔 P1이 한번만 들어가고 안들어가기 때문에 P0차례를 만들어주지 못한다. (차례를 바꿔 주려면 일단 들어갔다가 나올때 바꿔줌으로..)

P0는 영원히 못들어가게 된다...

=> turn을 교대로만 해주면 안되겠다.. 다른방법을 생각해 보자!

* Algorithm 2 

: flag가 포인트

# Critical Section에 접근하는 방법

[단계 1] Critical Section에 들어가려면 flag를 true로 바꾼다.

[단계 2] 상대방 flag를 chk한다.

(IF, 상대방 flag가 true가 있으면 기다린다.)

[단계 3] 들어갔다 나올때 flag를 false로 바꿔준다.

# 이 알고리즘의 문제??

: Critical Section에는 아무도 안들어 갔는데 P0와 P1이 동시에 true로 한 경우. 이 경우에는 끊임없이 서로 양보하는 상황이 발생.

=> flag를 이용하는 알고리즘도 Progress는 충족시키지 못했다.... 다른 방법을 생각해 보자!

* Algorithm 3 (Perterson`s algorithm)

: turn과 flag 모두 사용.

# Critical Section에 접근하는 방법

[단계 1] Critical Section에 들어가려면 flag를 true로 바꾼다.

[단계 2] turn을 상대방 turn으로 바꿔 놓는다.

[단계 3] turn과 상대방 flag를 chk한다. 

(IF, 상대방의 flag가 true이고, turn도 상대방이면 기다린다.)

[단계 4] 들어갔다 나올때 flag를 true로 바꿔준다.

=> 조건 3가지(Mutual Exclusion, Progress, Bounded Waiting) 모두 만족

But, 이 코드의 문제점이 있다.

# Spin Lock(= Busy Waiting)

ex> p0한테 cpu 할당 시간이 왔을때, while (flag [j] && turn == j);에서 빠져 나가지 못 할 경우도 있다.

      결국 자신의 cpu할당 시간에 3번째 구간에서 chk만하다가 끈나는 경우.

=> 즉, 비효율 적인 방법을 나타냄

cf> instruction 단위로 time sharing이 일어나서 cpu 사용권이 바뀌기 때문에 이런 문제가 발생한다!

=> Spin Lock의 해결법은 나중에 알아보도록 하자!

!!!) 사실은 H/W 적으로 하나의 Instruction만 주어지면 이러한 critical section문제는 아주 쉽게 해결이 된다. => Test_and_Set

cf> : Data를 읽는것과 쓰는것을 하나의 instruction으로 처리할수 없기 때문에 동기화 문제가 발생한다.

* Synchronization Hardware

# 보라색 그림 설명

: a라는 데이터를 읽어내고, 그다음에 a라는 데이터 값을 1로 바꿔주는 것을 하나의 instruction으로 처리 해준다.

cf> 여기서 1은 lock = 1(true)를 의미 한다.

#6-1. Process Synchronization
: os에서의 race condition 3가지의 예시와 해결방법에 대해 알아보도록 하자!

[INTRO]

* 데이터의 접근

# Execution Box : 연산하는곳
  Storage Box   : 데이터가 저장된곳

#데이터를 연산을하고 수정을하고 데이터를 저장하는 방식은 누가 먼저 읽어 갔느냐에 따라 결과가 달라질수도 있고, 그렇게 했을때 생기는 문제를 Synchronization 문제라고 하고, 이것을 해결할수 있는 방법을 여기서 공부한다.

* Race Condition (경쟁상태)

# count++ 와 count--가 동시에 접근할때 count에 문제가 생긴다. 이런 경우, Race Condition의 가능성이 있다.

# 이것을 조율해줘야 하는 방법이 필요하다!!! => Synchronization

# os에서 race condition은 언제 발생 하는가?

# user모드에서는 괜찮던게 os의 kernel에서는 여러 프로세스들이 공유하는 데이터들이 있기 때문에 문제가 생긴다. 이 예시들을 자세히 알아보자

* os에서의 race condition (1/3)
: kernel mode 수행중에 interrupt 처리가 들어왔을때.

# count++(1 증가 시키는 문장) :
1. load : 메모리에 있는 값을 cpu 안에있는 register로 불러 들이고,
2. Inc : 그 값을 1 증가 시키고,

3. Store : 그 다음에 레지스터 값을 다시 메모리에 저장.

# 그러나, 저 루틴 수행 과정중 interrupt가 들어왔을 경우에 저 작업을 잠시 멈추고 interrupt 처리 루틴으로 넘어가게 된다.

(Interrupt Handler : 근데 이게 kernel 코드이다.)

# 이렇게 되면 감소시킨 것을 반영이 안되고 증가하는 것만 반영이 되게 된다.

???) 어떻게 해결 하는가?
: disable, enable interrupt로 해결 한다!

저런 오류가 일어 나지 않게 count++가 시작되면 disable interrput가 시작되어 interrupt를 받아들이지 않는다.

 count++연산이 끈나면 enable interrupt가 시작되어 다시 interrupt를 받을수 있는 상태로 전환 된다.

* os에서의 race condition (2/3)
: 공유 공간인 kernel mode에서 cpu할당시간이 끈났을 때

# 본인의 코드만 실행하는것이 아니라 System call을 통해서 os에 서비스를 대신해 달라고 하는 경우가 있다. 그래서 프로그램은 user mode와 kernel mode를 번갈아 가면서 실행을 하게 된다.

# A라는 프로그램은 cpu를 독점적으로 쓰느게 아니라 할당시간이 있고, 할당시간이 끈나면 cpu를 반납하게 되어 있다.

# 이 그림에서는 A가 cpu를 쓰다가 할당시간이 끈나서 cpu가 B한테 넘어간 것 이다. 그래서 B가 cpu를 쓰다가 본인의 할당시간이 끈나서 다시 A한테 넘어오는 그림이다.

# 여기서 문제점은 user mode일때 cpu가 반환되면 상관없는데, system call로 이해 kernel mode로 들어간 후에 cpu사용권을 반납했다. A, B 모두 kernel mode라는 공유공간에서 count를 건드리는 작업을 하기 때문에 문제가 발생하게 된다.

# 이 경우에는 논리적으로는 +2가 증가해야 되는데 B의 +1은 반영이 되지 않게 되는 문제가 발생한다.

???) 어떻게 해결하고 있는가?
: 프로세스가 kernel mode에 있을때는 할당시간(time quantum)이 끈나도 cpu를 뺏기지 않도록 하고 있다.

* os에서의 race condition (3/3)
: cpu가 여러개 있는 환경.(즉, 작업 주체가 여러개 있는 상황)

???) 어떻게 해결 할까?
: 데이터에 lock 과 unlock을 걸어서 이중접근을 방지 시킨다.

* Process Synchronization 문제

* The Critical-Section Problem
cf> Critical-Section(임계구역) : 공유 데이터를 접근하는 코드(critical section은 코드임에 주의!!!)

 
# 다음시간에 이 문제를 해결하는 알고리즘을 알아보자!

#5-3. CPU SCHEDULING

cf> 여태까지 스케줄링은 큐에서 한줄서기를 하면서 cpu사용을 기다려 왔지만,

      Multilevel queue와 Multilevel feedback queue는 여러줄 서기를 할 수 있다!!

* Multilevel Queue

# 밑에 그림을 통해 우선순위를 알수 있다.
: 맨 위에 줄이 우선순위가 높으며, 밑으로 갈수록 우선순위가 낮아진다.

# system process : 시스템과 관련된 일을 하는 프로세스
  interactive Process: 사람하고 관련된 일을 하는 프로세스
  interative editing process : 그것보다는 살짝 인터렉션이 떨어지는 프로세스
  batch process : cpu만 오랫동안 사용하는 프로세스를 여기서는 batch process라고 얘기를 하는것 같다.
  student process : 학생을 무시하는건가....?

=> 여기는 완전 계급제!
 즉, 맨 위에 부터 비어있나 확인을 해서 밑으로 내려간다. 밑에 있는 프로세스는 영원히 cpu할당을 못 받을 수 도 있다.(starvation 발생)

cf> 반면에!!
Multilevel Feedback Queue는 완전 계급제는 아니다. 방탕하게 살면 우선순위가 떨어지기도 하고 열심히 살면 우선순위가 올라가기도 한다!!

 (다음에 나오는 Multilevel Feedback Queue 그림 참고하기!!)

# 고려해야 할점?

 - Ready queue를 여러 개로 분할
  v. foreground (interactive)
  v. background (batch-no human interaction)

 - 각 큐는 독립적인!! 스케줄링 알고리즘을 가짐.
  v. foreground  => RR
  v. background  => FCFS

 # 줄에 특성에 맞는 queue별 스케줄링을 채택! (이렇게 채택된 이유를 알겠지?)

 - 큐에 대한 스케줄링이 필요
  v. Fixed priority scheduling
    # 이 방식은 우선순위를 아주 강하게 주어 우선순위만을 사용하는 방식인데, 이렇게 되면 우선순위가 낮은 프로세스들은 starvation이 발생한다. 이에대한 해결책이 Time slice!!

  v. Time slice

  - 각큐에 CPU TIME을 적절한 비율로 할당
     ex> 우선수위 높은 RR은 80%주고, 낮은 FCFS는 20%주고!

* Multilevel Feedback Queue

# (Multilevel queue와 비교하여)고려해야될 점
(사진의 빨간색 글씨 부분들!!! (중요!))

# 우선순위가 높으면 RR의 quantum을 짧게 해주며, 우선순위가 낮아질수록 quantum을 높여줘서 나중에는 FCFS가 되게끔 한다.

-----------------------------------------------------------------------------------------------------------------------
# 여기까지는 CPU가 하나일때의 CPU SCHEDULING 이었다면, 지금부터의 내용은
CPU가 여러개 일 경우,
Thread가 여러개일 경우,
등등 특이한 case의 cpu스케줄링을 알아 보겠습니다.

* Multiple-Processor Scheduling
: 이 부분은 화두만 보고 넘어가자!

# Load sharing : 하나의 줄에만 부하되는것을 막는 것.

# Symmetric Multiprocessing : cpu가 모두 대등한 것.

# Asymmetric Multiprocessing : 하나의 cpu가 컨트롤을 담당하고 나머지가 그 cpu를 따르는 것.

* Real-Time Scheduling
: 반드시 데드 라인을 보장해야 한다.

# 그때 그때 스케줄링하기보다는 real time job들이 정해져 있고, 그것들을 미리 스케줄링해서 데드라인이 보장되도록 적재적소에 배치되도록 하는 그런 시스템을 쓰고 있다.

cf> real time job : dead라인이 있는 job!
    (정해진 시간안에 완료해야하는 작업이 있는 job)

# hard는 데드라인이 꼭 지켜져야 하고
  soft는 데드라인을 지켜야하는 의무가 좀더 부드럽다.

* Thread Scheduling

cf> Thread : 프로세스 하나 안에 cpu 수행단위.

# User level Thread : 사용자 프로세스가 직접 쓰레드를 관리하고 os는 그 쓰레드를 모르는 상황. => 그래서 os가 프로세스에게 cpu사용권을 주면 그 프로세스 내에서 어떤 쓰레드에게 cpu사용권을 줄지를 결정하는 것. => "Local Scheduling"

# Kernel level Thread : os가 쓰레드의 존재를 이미 알고 있는 상황. => 그래서 kernel의 단기 스케줄러가 cpu사용권을 결정하는 것. => "Global Scheduling"

* 알고리즘 성능 평가

cf> trace : 실제 프로그램을 통해 추출한 input data.