process scheduling은 크게 두가지로 나뉜다.
1. real-time process - 1.hard real-time(산업용), 2.soft real-time(vedio decoder 등)
2. time-sharing process
여기서 time-sharing 을 설명한다.
Linux에서는 크게 두가지의 thread를 지원한다.
1. Kernel - 1. Kernel Thread, 2. LWT(Lightweight Thread)
2. User Thread
thread를 사용할때 중요한것이 동기화인데, context switch를 할 때 데이터가 저장이 안된 상태에서 다른 thread로 우선순위가 넘어가면 치명적인 오류가 나게된다.
Linux에서 멀티 프로세스 개념인 fork()는 내부적으로 do_fork()란 Kernel 함수를 호출하며, do_fork()는 내부적으로 user thread인 POSIX기반의 Mutex를 사용한다.
... 그리고... 한가지... POSIX thread를 사용하여 많은 양의 thread를 생성하면 동기화를 주목해야한다.
설계가 관건이다. 설계를 잘해야한다. 사소한 실수라도 하면 끝이다.
... mutex 동기화... 미치겠군... 데이터를 수정할때는 lock을 걸 수 있는데 변수 초기화때 context switch가 일어나면 어쩌자는거냐.
여담으로... context switch시 PCB(Process Control Block)에 정보가 저장된다.
이것은 Assembly어로 짜여지며 그 이유는 속도 때문이다.
PCB에 저장된 양이 적어야 process간 전환이 빠르다.
-> 만약 Zombie Process가 생성되면 시스템 자원을 먹지는 않지만 PCB가 좀비프로세스의 리턴 값으로 늘어나 시스템이 전반적으로 느려진다.
~cpp
void *thread(void *arg)
{
int num = *(int *)arg;
int i;
for(i=1; i<=20; i++){
pthread_mutex_lock(&mutex);
printf("%d: sum+=%d\n", num, i);
sum += i;
sleep(1);
pthread_mutex_unlock(&mutex);
}
}
thread를 10개 생성 시키고 이 작업을 수행하면,
함수가 실행되고 context switch가 일어나고 arg가 제대로 안바뀌는 것 같다.
arg는 0~9까지가 아닌 몇몇의 중복되는 수로 나타나게 된다.
pthread_mutex_lock을 변수 앞에 걸어주면 arg는 0으로 채워지게된다.
아직까지 생각 중이지만 pthread의 내부적 문제인것 같다.
명확한 지식이 있기전까진 arg의 값은 믿을 수 없다. 이상.
Critical Section이 아닌데도 데이터가 제대로 바뀌지 않는다.
이상하다. 소스에는 문제점이 없지만 약간 많은 쓰레드가 동시에 생성되고 데이터 처리 양이 많을 때에는
argument가 제대로 넘겨지지 않는 것 같다.
function에 argument를 넘기는 것은 stack에 관계된 것이고, 개개의 쓰레드는 각각의 stack을 가지고 있을텐데. 아직 생각중이다.