week6_0501.md

• 스핀락과 세마포어의 특징을 설명하고, 스핀락과 세마포어 각각을 어느 조건 속에서 사용하면 좋은지를 둘의 차이점을 근거로 하여 설명하시오.

  • 스핀락

    • 락을 획득할 때까지 루프를 돌며 락 획득이 가능한지 검사한다.
    • 휴면 상태로 전환되지 않는다.
    • 커널 선점이 불가능하다.
    • 재귀적으로 구현되지 않아 락을 획득한 프로세스가 다시 락 획득을 시도한다면 데드락에 빠진다.
    • 락 사용시간이 곧 스케줄링 지연시간이 된다.

  • 스핀락 에서 커널 선점 비활성화의 이유

    • 데드락 을 방지하기 위한 목적이다. 만약 스핀락 에서 커널 선점이 가능하다 가정하고 사용자 프로세스 가 스핀락을 얻은 시점에 인터럽트 가 발생하여 사용자 프로세스 를 선점한 상황을 생각해보자. 인터럽트 수행 중에 사용자 프로세스가 획득한 스핀락 을 얻으려 한다면 인터럽트는 무한 루프를 돌며 락 획득이 가능한지 검사를 하지만 인터럽트 컨텍스트 에선 선점될 수 없음으로 사용자 프로세스가 락을 해제하는 일은 일어나지 않아 데드락 에 빠진다. 처음에 사용자 프로세스가 스핀락을 획득했을 때 커널 선점을 비활성화 하여 이러한 상황을 방지할 수 있다.

  • 세마포어

    • 락 획득에 실패하면 휴면 상태로 전환된다.
    • 락을 획득한 프로세스가 unlock 해준다면 첫 락 획득 실패로 휴면에 빠진 프로세스를 깨워준다.
    • 프로세스 컨텍스트에서만 실행된다.
    • up(), down() 함수로 락을 관리하며, 이 함수 이외의 추가적인 시스템 콜을 필요로 하지 않는다.

  • 세마포어 는 왜 커널 선점이 가능하게 설계 되었는가?

    • 선점할 수 없는 락 상황에서 락의 사용시간이 길어지면 한 프로세스가 프로세서를 독점하게 되고 스케줄링이 지연된다. 이를 보완하기 위해 선점이 가능한 세마포어 는 락 사용시간이 길어도 스케줄링 대상에 포함되어 인터럽트나 우선순위가 높은 프로세스가 오면 스케줄링 되어 프로세서를 독점하는 상황은 발생하지 않는다. 설령 다른 프로세스가 락 획득을 시도해도 락이 걸려있다면 바로 휴면 상태로 전환되기에 스핀락 에서의 데드락 상황은 발생하지 않는다.

  • 스핀락 과 세마포어 의 유리한 상황 비교

    • 스핀락
      • 락 사용시간이 짧은 경우
        • 근거
          • 세마포어 는 락을 얻지 못하면 휴면 상태로 진입하기 때문에, 프로세서를 낭비할 일이 적은 것이 장점이다. 그러나 락을 얻은 후 짧은 시간 실행될 프로세스들을 세마포어 를 이용하여 동기화한다면, 휴면 상태 전환 및 대기큐 관리, 태스크 깨우기 등의 오버헤드가 특정 프로세스의 락 사용 시간을 넘어설 수 있다. 따라서 이러한 상황에서는 세마포어 와 달리 락 구현에 시스템 호출을 사용하지 않는 스핀락 을 사용하는 것이 효율적이다.
      • 인터럽트 컨텍스트에서 락을 사용하는 경우
        • 근거
          • 인터럽트 컨텍스트 에 있는 프로세스는 휴면 상태로 전환될 수 없다. 따라서 이 경우에는 세마포어 를 쓸 수 없고, 스핀락 을 사용해야 한다.
    • 세마포어
      • 락 사용시간이 긴 경우
        • 근거
          • 락을 얻은 프로세스들의 락 사용 시간이 긴 경우에 스핀락 을 사용한다면, 락 획득에 실패한 프로세스는 무한루프를 돌면서 프로세서를 독점한다. 이는 성능 저하의 원인이 되므로 이 경우에는 세마포어 를 사용하는 게 좋다.
      • 락을 얻은 상태에서 휴면할 필요가 있는 경우
        • 근거
          • 스핀락 으로는 프로세스를 휴면 상태로 전환할 수 없으므로, 락을 얻은 프로세스가 휴면할 필요가 있을 때는 세마포어 를 사용해야 한다.

• 재귀적인 락은 어떻게 구현되며 언제 사용하는가?

  • 락을 가진 프로세스가 다시 자신의 락을 검사하면서 빠지는 데드락을 방지한다. 스핀락의 경우 자신이 획득한 락을 다시 얻으려 한다면 락을 다른 누군가가 사용하고 있다고 판단해 락 해제를 계속 기다리게 되는 데드락에 빠진다. 이를 방지하기 위해 재귀적 락의 구현에서는 락 획득 검사 과정에 자신이 획득한 락을 다시 획득할 수 있게 구현을 했으며, 재귀적으로 락을 획득했다면 획득한 만큼 언락을 해주어야 한다.

  재귀적인 락 구현할 때 획득 조건에 획득하려는 락을 자신이 가졌는지 검사 후에 락 획득을 시도하는 것이 아닌가 추측된다.

• 배리어 의 필요성을 설명하고 배리어 함수들의 기능에 대해 논하시오.

  • 배리어 의 필요성
    • 컴파일러는 코드 간의 의존성 을 기준으로 코드 재배치가 가능한지 판단하고, 이러한 재배치 작업으로 코드를 최적화 할 수 있다. 그러나 코드 간의 의존성이 없다고 하더라도 멀티스레드 환경에서는 코드가 순서대로 실행될 것을 보장해야 할 때가 있다. 이때 배리어 가 필요하다.
  • 배리어 함수
    • rmb()
      • rmb()함수 전후로 읽기 명령이 재배치되는 것을 막는다.
    • wmb()
      • wmb()함수 전후로 쓰기 명령이 재배치되는 것을 막는다.
    • mb()
      • mb()함수 전후로 읽기 및 쓰기 명령이 재배치되는 것을 막는다.
    • read_barrier_depends()
      • read_barrier_depends()함수 전후로 의존성 이 있는 읽기 명령이 재배치되는 것을 막는다.

• 락을 구현할 때 신경써야 할 사항들에는 어떤 것들이 있는지 논하시오.

  • 보호 대상 인식
    • 어떤 데이터가 락을 필요로 하는가?
    • 이 데이터가 전역 데이터인가? 다른 프로세스 또는 스레드에서 접근이 가능한가?
    • 서로 다른 두 인터럽트 핸들러가 해당 데이터를 공유하는가?
    • 프로세스가 데이터를 다루다가 선점 당하고, 선점한 프로세스가 같은 데이터에 접근할 가능성이 있는가?
    • 현재 실행 중인 프로세스가 휴면 상태로 전환될 수 있는가? 그렇다면 공유 데이터는 어떤 상태가 되는가?
    • 이 데이터 또는 코드가 동시성에 대해 안전한가? 어떻게 그 사실을 확신할 수 있는가?
  • 얼마나 세세하게 락을 구현해야 하는가?
    • 경쟁과 확장성
      • 경쟁
        • 락이 세분화되어있지 않다면 임계 구역의 한 지점에 접근할 때도 임계 구역 전체에 락을 걸게 된다. 이렇게 되면 프로세스 간 락을 얻기 위한 경쟁이 심해지고, 이는 시스템 병목의 원인이 된다.
      • 확장성
        • 락이 세분화되어 있다면 경쟁으로 인한 시스템 병목 현상이 줄어들어 확장성에 도움을 줄 수 있다. 그러나 너무 세분화된 락은 작은 시스템에서는 불필요한 오버헤드가 될 수 있다. 따라서 확장성과 성능 사이의 균형이 중요하다.

    간단하게 시작하고 필요한 경우에만 복잡도를 높이도록 하자. 단순함이 핵심이다.