티스토리 뷰

### Readers and Writers Problem ###

: database에서 공유데이터에서 접근하는 여러개의 concurrent processes(writers, readers)가 있다.

: writer process가 공유 데이터에서 데이터를 수정할 때

다른 concurrent process가 들어오면 data consistency에 문제 발생

( 같은 시간에 예방책

=> 공유 데이터을 critical section으로 해두고 mutual exclusion을 하여 data inconsistency를 예방한다 )

 

: Reader - data set만 읽을 수 있지만 update 할 수 없다

 

: Writer - shared data를 읽고 쓸 수 있다

 

int read_count = 0; //현재 critical section에 접근한 reader process의 개수
semaphore rw_mutex = 1; //lock 변수 (모든 것을 막지 않는다 -> writer/reader에 따라 달라진다.)
semaphore mutex = 1; //mutex가 1일 때 다른 reader process도 접근 할 수 있게 해준다.

// writer process
while (true){
	wait(rw_mutex);
    
    // writing을 수행
    
    signal(rw_mutex);
}


// reader process 
while (true){
	wait(mutex);
    read_count++;
    
    if (read_count == 1){
    //다른 reader process 접근 가능
    	wait(rw_mutex);
    }
    signal(mutex);
    
    // reading을 수행
    
    wait(mutex);
    read_count--;
    
    if (read_count == 0){
    // 다른 reader process 접근 불가능
    	signal(rw_mutex);
    }
    siganl(mutex);
}

 

 

 

<Stravation(기아) in Readers and Writers Problem>

1. < First readers and writers problem >

: reader process에 writer process보다 우선순위를 주는 것

=> 대기 중에 writer process가 있더라도 reader process가 먼저 공유 데이터에 접근할 수 있도록 하여 생기는 문제

==>> Writers in starvation 발생 (writer process가 접근 할 수 없다)

2. < Second readers and writers problem >

: 정확한 최신 데이터를 보장하는 곳에서는 이런 문제가 발생

: writer process에 reader process보다 우선순위를 주는 것

=> 대기 중에 reader process가 있더라도 writer process가 먼저 공유 데이터에 접근할 수 있도록 하여 생기는 문제

==>> Readers in starvation 발생 (reader process가 접근 할 수 없다)

반응형
공지사항
최근에 올라온 글