Oracle Mutex 구현 메커니즘

Latch 는 Oracle 이 메모리 에서 직렬 통 제 를 하 는 기구 라 는 것 을 잘 알 고 있 습 니 다. 10g R2 부터 Oracle 은 새로운 기술 - Otex 를 도입 하 였 습 니 다.Mutex 는 Oracle 의 발명 이 아니 라 시스템 이 제공 하 는 바 텀 호출 입 니 다. Oracle 은 이 를 이용 하여 직렬 제어 기능 을 실현 하고 일부 Latch 를 교체 할 뿐 입 니 다.
Mutex 에는 두 가지 변수 가 있 습 니 다. 각각 Holider idenifer 와 Reference count, Holider idenifer 는 mutex 를 가 진 SID 를 기록 하고 있 으 며, Reference count 는 하나의 계수 로 현재 share 방식 으로 mutex 를 방문 하고 있 는 수량 을 기록 하고 있 습 니 다. session 이 share 방식 으로 mutex 를 가 질 때마다 계수 가 1 을 더 하고 방출 할 때 1 을 줄 입 니 다.Reference count 가 0 보다 크 면 이 메모리 구조 가 Oracle pin 에 살 고 있 음 을 나타 낸다.
우 리 는 가짜 코드 를 보고 mutex 의 신청 과정 을 보 여 줍 니 다.

Function Mutex_get(mutex_name)
{
  if mutex.holder:=SID
    case mode:
    'exclusive':
      if mutex.ref_count=0
        return TRUE
      else
        mutex.holder.clear;
        reture FALSE
      end if
    'share':
      mutex.ref_count++
      mutex.holder.clear
      return TRUE
    end case
  else
    reture FALSE
  end if
}

Mutex 는 직렬 통 제 를 어떻게 실현 하 는 지 실제 적 으로 운영 체제 의 원자 조작 CAS (copare - and - swap) 를 이용 하여 이 루어 졌 다.함수 의 시작 부분 을 보 았 습 니 다: mutex. holder: = SID, mutex 의 Holider Identifer 에 SID 를 할당 합 니 다. 여 기 는 원자의 CAS 작업 입 니 다. 먼저 mutex. holder 가 비어 있 는 지, 비어 있 지 않 으 면 session 의 SID 를 비교 합 니 다.CAS 조작 은 OS 에 의 해 원자 성 을 확보 하고 같은 시간 에 이 조작 소 는 직렬 이다.만약 이 할당 작업 이 실패 하면 전체 신청 과정 이 실패 합 니 다.할당 성공 후 share 방식 이 라면 mutex. refcount 에 1 을 추가 하고 mutex. holder 를 비 웁 니 다. exclusive 방식 이 라면 mutex. ref 를 판단 해 야 합 니 다.count 가 0 인지 여부 (pin 에 사 는 지 여부), 0 이상 이면 실패 하고 mutex. holder 를 비 웁 니 다. 0 과 같 으 면 성공 합 니 다. 이 때 mutex. holder 를 비 우지 않 고 현재 session 이 mutex 에 대한 exclusive 점용 을 유지 합 니 다. 방출 될 때 까지.
Mutex 는 latch 에 비해 다음 과 같은 장점 을 가 져 왔 습 니 다.
1. 더 적은 자원 소모, mutex 는 latch 와 달리 독립 적 으로 존재 하 는 것 이 아니 라 모든 메모리 구조 에서 메모리 구조 가 생 성 되 고 방출 되면 서 mutex 는 생 성 되 고 방출 된다.mutex 가 일시 적 으로 사용 하 는 공간 은 latch 보다 훨씬 작고 소모 가 적은 자원 을 만 들 고 방출 합 니 다.
2. 경쟁 을 효과적으로 낮 출 수 있 습 니 다. mutex 는 모든 메모리 구조의 일부분 이기 때문에 mutex 의 수량 이 많 을 수 있 습 니 다. latch 와 달리 하나의 latch 는 여러 개의 메모리 구 조 를 관리 해 야 합 니 다. 같은 latch 가 관리 하 는 서로 다른 메모리 구 조 를 방문 할 때 경쟁 이 발생 하지만 mutex 는 그렇지 않 습 니 다.또한 latch 의 수량 이 제한 되 어 있 기 때문에 latch 자체 의 경쟁 이 심 할 때 가 많 습 니 다. 그 전에 우 리 는 latch 의 수량 을 늘 리 거나 latch 가 가지 고 있 는 시간 을 줄 일 수 밖 에 없 었 는데 지금 은 mutex 가 더 좋 은 선택 입 니 다.
3. 더 빠 른 pin, block 이 접근 할 때, 이것 은 반드시 pin 이 buffer cache 에 있어 야 합 니 다. cursor 가 실 행 될 때, 이것 도 반드시 pin 이 library cache 에 있어 야 합 니 다. 만약 에 같은 cursor 를 대량으로 동시 다발 적 으로 실행 하면 library cache pin 은 대량의 CPU 자원 을 소모 합 니 다.한편, mutex 는 reference count 를 사용 하여 동시 방문 문 제 를 해결 합 니 다. 0 이상 이면 pin 이 메모리 에 있 고 교환 할 수 없습니다.그리고 mutex. refcount + + 이 체 조 는 매우 빠 르 고 매우 적은 자원 만 점용 합 니 다.
Mutex 가 신청 하 는 과정 은 latch 와 유사 하 며 spin 과 sleep 가 필요 합 니 다. 다른 것 은 Oracle 이 mutex spin 을 하 드 코딩 한 횟수 가 255 회 (Latch spin 의 횟수 는 기본적으로 2000 이 고 함 축 된 매개 변수 spin count 가 제어 합 니 다) 입 니 다.latch sleep 는 대기 횟수 가 증가 함 에 따라 매번 sleep 의 시간 도 점점 증가한다.한편, mutex sleep 는 특히 세 가지 옵션 이 있 는데 그것 이 바로 yield CPU, sleep 또는 block other process 로 개발 자 들 이 어떤 옵션 을 사용 할 지 결정 할 수 있 습 니 다.
일부 RISC 운영 체제 (HP - UNIX) 에서 시스템 이 CAS 작업 을 지원 하지 않 기 때문에 Oracle 은 latch pool 을 만들어 CAS 작업 을 모 의 했 습 니 다. KGX latch 라 고 불 립 니 다. 시스템 에 이러한 latch 경쟁 이 존재 하 는 것 을 발견 하면 운영 체제 가 CAS 작업 을 지원 하지 않 는 다 는 것 을 의미 합 니 다.kks_use_mutex_pin mutex 닫 기.
mutex 는 주로 library cache 에 사용 되 는데 원래 의 library cache pin 과 library cache lock 을 대체 하 는 데 사 용 됩 니 다. library cache 의 잠 금 실현 체제 에 대해 저 는 다른 글 에서 설명 하 겠 습 니 다.