핀토스 삽질기록 9/20

핀토스 프로젝트2 시스템콜 구현 중

read()

시스템 콜 구현 중 파일 읽기 시 lock을 사용한 코드를 보았다.

int
read (int fd, void *buffer, unsigned size) {
    check_addr_validity(buffer);
    if (!(0 <= fd < FD_LIMIT)) return -1;

    int readsize;

    if (fd == STDIN_FILENO) {
        char c;
        unsigned char *buf;
        for (readsize = 0; readsize < size; readsize++) {
            *buf = input_getc();

            if (*buf == '\n') break;
            else buf++;
        }
    }

    else if (fd == STDOUT_FILENO)
        return -1;

    else {
        struct thread *t = thread_current();
        struct file *file = t->fdt[fd];
        lock_acquire(&filesys_lock); // 이 부분
        readsize = file_read(file, buffer, size);
        lock_release(&filesys_lock); // 이 부분
    }

    return readsize;
}

Pintos에서는 lock이 굳이 필요가 없을 것 같아서 생각을 정리해보았다.

1. lock이 필요한 이유: 프로세스 내에서 파일 디스크립터마다 위치가 존재한다. read함수는 현재 위치로부터 일정한 바이트 수만큼을 읽어들인다. 이 위치가 중간에 변경되지 않도록 lock이 필요하다.
2. lock이 필요하지 않은 이유: 멀티 스레딩을 지원하는 운영체제면 여러 스레드가 같은 파일 디스립터를 이용해 동시에 접근할 수 있다. 하지만 핀토스는 유저 프로세스가 하나의 스레드만 가지고 있으므로 굳이 lock이 필요하지 않다. 또한 lock을 걸더라도 파일 별로 lock을 지정해야하지 전역변수로 프로세스에 속한 스레드들을 대기시키는 것은 비효율적이다.

그래서 나는 lock을 안 썼다.