(2022.03.27) Synchronization 가이드라인 (1)

아직 프로젝트 4 관련해서는 아무것도 한 게 없지만 가장 중요해보이는 것을 먼저 가져왔다. 결국 프로젝트 1부터 프로젝트 3까지 내가 사투를 벌여온 영역은 동기화 문제였고, 파일 시스템 동기화와 관련하여 가장 머리를 싸맨 기억이 많았다. 디버깅할 때 가장 엿같았던 기억을 선사한 것도 동기화 문제기에, 이쯤되면 동기화는 발작 버튼으로서 훌륭한 기능을 하게 되었다.

 

여태까지 파일 시스템은 내부 동기화 과정이 없어, 외부 동기화로 호흡기를 붙여야 간신히 호흡을 할 수 있는 상태였다. 그렇기에 코드가 조잡해졌고, 많은 프로세스를 돌릴 때, 락이 필요없는 부분까지도 락이 걸려있어야 하는 비효율성을 초래했다. 때문에 finer-grained 동기화 전략을 구현하는 것이 해당 파트의 목표이다. 각 엔티티에 따른 동작은 분리되어 있어야 하며, 서로가 서로를 기다리지 않고도 진행되어야 한다.

 

다른 cache 블록에 가해지는 작업은 독립되어야 한다. 한 블록에 IO가 진행 중일때 다른 블록에 가해지는 IO는 상식적으로 기다릴 필요가 없다. 

 

복수의 프로세스가 하나의 파일에 동시에 접근할 수 있도록 해야 한다. 읽기는 물론 쓰기까지도. 아니 그게 대체 무슨 소리냐고 할 수 있다. 읽기를 하는 프로세스들은 몇 개가 접근하든지 상관 없다는 것은 직관적으로 이해가 될 것이다. 그럼 쓰기는? extend를 하지 않는 한, 쓰는 것 또한 여러 프로세스가 하나의 파일에 접근할 수 있다고 한다. 그럼 쓰는 사이에 읽는 건 어떻게 처리되는지 궁금할 수 있는데, 아무것도 안 써졌거나, 전부 다 써졌거나, 부분만 써진 상태로 읽어지는 것이 모두 허용된다고 한다. 단, write syscall이 반환이 된 이후에는 모든 reader가 변화를 볼 수 있어야 한다. 완전히 대혼돈 상태가 될 것 같은데 이걸 허용한다고 하니 뭐 할 말이 없다.

 

extend 할 때는 상황이 달라진다. 파일을 늘릴 때와 해당 부분에 글을 써 넣는 행위는 atomic하게 일어나야 한다고 나와있다. 만약 이 작업이 진행됨과 동시에 파일 읽기가 진행이 된다면, 읽기는 진행이 가능하되, 아무것도 못 읽거나, 부분만 읽거나, 전체를 읽게 된다. 이에 대한 구현을 테스트하는 것으로 syn-rw가 제공된다. 해당 테케는 부모 프로세스가 4개의 자식 프로세스를 만든다. 부모 프로세스는 파일 크기를 점차 늘려가면서 random byte를 파일에 쓰고 자식 프로세스는 그와 동시에 파일을 읽으면서, 읽은 파일의 내용이 일치하는지를 검사한다. 주석에는 이러한 설명이 있다.

/* Child process for syn-rw.
   Reads from a file created by our parent process, which is
   growing it.  We loop until we've read the whole file
   successfully.  Many iterations through the loop will return 0
   bytes, because the file has not grown in the meantime.  That
   is, we are "busy waiting" for the file to grow.
   (This test could be improved by adding a "yield" system call
   and calling yield whenever we receive a 0-byte read.) */

즉, 파일이 extend 되기 전에는 read의 반환값이 0으로 유지될 것이라는 말이며, atomic하게 파일의 크기를 extend하고 내용을 쓴 뒤에는 read의 반환이 제대로 이루어질 것이라고 추측할 수 있다. 해당 부분을 atomic하게 만드는 것에 락이 들어가야 할 것이다.

 

그 외 기타 사항으로는:

 

• 다른 directory 내 작업 또한 기다릴 필요 없이 동시 진행되어야 하며, 동 디렉토리 내에서는 한 프로세스가 다른 프로세스를 기다리는 것을 허용한다고 한다.
• 기본 파일 시스템에서는 struct file과 struct dir이 오직 한 thread에 의해 접근된다고 가정한다.
• 동시에 여러 thread에 의해 접근되는 데이터만 동기화될 필요가 있다고 하니 유의하도록 하자.

이 있다.

 

사실 동기화 구현의 내부화에 대한 검사는 어떻게 진행할 수 있을지 생각해봤다. 마땅한 방법이 없는 것 같고, 이에 제공된 테스트 케이스도 정말 최소한의 검사만 진행할 수 있도록 짜여져 있다. 그래서 다 읽어보니 이걸 과연 구현해야 할까라는 심정이다. 현재 내 구현에서 filesys_enter가 사용된 횟수는 총 21번. 많다고는 할 수 없지만 그래도 하나하나씩 잡기에는 좀 귀찮은 정도이다. 일단 처음 인상에 비해서는 중요도가 다른 것들에 비해서는 다소 낮아보이니, 프로젝트를 모두 끝낸 뒤에 생각만 하고 넘어가도록 하자.

 

사실 예전에는 buffer cache도 비슷한 문제를 가지고 있었다. 구현해도 검사할 수 있는 방법이 없어서 구현하나 안하나 동등한 수준이었다. 그래도 이번에는 buffer cache를 위해 테케가 구현이 되어 있어서 내가 올바르게는 만들었구나 하는 생각이 들 수는 있을 것 같다. 그래도 동기화는 테케를 만들기가 뭣 같은 부분이니 이해는 간다. 그럼 다음 포스팅에서는 본격적으로 구현을 할 Indexed and Extensible Files 파트를 살펴보도록 하겠다.