읽 기 및 쓰기 잠 금 (read - write lock) 메커니즘 - 다 중 스 레 드 동기 화 문제 해결

읽 기와 쓰기 자물쇠 (read - write lock)

        ReadWriteLock rwlock=new ReentrantReadWriteLock();
        rwlock.writeLock().lock();//  

        rwlock.readLock().lock();    //  

종합 하여 서술 하 다
   
일부 프로그램 에 독자 작성 자 문제 가 존재 한다. 즉, 일부 자원 에 대한 방문 회 이다.  두 가지 가능 한 상황 이 존재 합 니 다. 하 나 는 방문 이 반드시 줄 을 서 야 한 다 는 것 입 니 다. 바로 독점 이라는 뜻 입 니 다. 이것 을 쓰기 조작 이 라 고 합 니 다.또 다른 상황 은 방문 방식 을 공유 할 수 있다 는 것 이다. 즉, 여러 개의 스 레 드 가 동시에 특정한 자원 을 방문 할 수 있다 는 것 을 읽 기 작업 이 라 고 한다.이 문제 모델 은 파일 에 대한 읽 기와 쓰기 작업 에서 파생 된 것 이다.진정한 의미 의 읽 기와 쓰기 가 아니다!
    읽 기와 쓰기 자 물 쇠 는 mutex 보다 더 높 은 적용 성 을 가지 고 더 높 은 병행 성 을 가 집 니 다. 여러 개의 스 레 드 가 동시에 읽 기 모드 의 읽 기와 쓰기 자 물 쇠 를 사용 할 수 있 지만 한 스 레 드 만 쓰기 모드 의 읽 기와 쓰기 자 물 쇠 를 사용 할 수 있 습 니 다. 읽 기와 쓰기 자 물 쇠 는 세 가지 상태 입 니 다.
1. 읽 기와 쓰기 자물쇠 가 쓰기 자물쇠 상태 일 때 이 자물쇠 가 풀 리 기 전에 이 자물쇠 에 자 물 쇠 를 넣 으 려 는 모든 라인 이 막 힙 니 다
2. 읽 기와 쓰기 자물쇠 가 읽 기와 잠 금 상태 에 있 을 때 읽 기 모드 로 잠 금 을 추가 하려 는 모든 스 레 드 는 접근 권 을 얻 을 수 있 지만 쓰기 모드 로 잠 금 을 추가 하 는 스 레 드 는 막 힐 것 입 니 다.
3. 읽 기 및 쓰기 잠 금 이 읽 기 모드 의 잠 금 상태 에 있 을 때 다른 스 레 드 가 쓰기 모드 로 잠 금 을 추가 하려 고 하면 읽 기 및 쓰기 잠 금 은 다음 읽 기 모드 잠 금 요청 을 차단 합 니 다. 그러면 읽 기 모드 잠 금 이 장기 적 으로 사용 되 는 것 을 피 할 수 있 고 기다 리 는 쓰기 모드 잠 금 요청 은 장기 적 으로 막 힐 수 있 습 니 다.
(2 와 3) 읽 기와 쓰기 자물쇠 가 읽 기와 자 물 쇠 를 추가 할 때 이 자물쇠 가 풀 리 기 전에 읽 기 모드 로 자 물 쇠 를 추가 하려 는 모든 스 레 드 에 접근 권 을 얻 을 수 있 습 니 다.쓰기 모드 로 자 물 쇠 를 채 우 는 스 레 드 가 막 히 고 다음 읽 기 모드 로 자 물 쇠 를 채 웁 니 다.이렇게 하면 읽 기 모드 잠 금 이 장기 적 으로 점용 되 는 것 을 피 할 수 있 고 기다 리 는 쓰기 모드 잠 금 요청 이 만족 하지 못 할 수 있 습 니 다.    읽 기와 쓰기 자 물 쇠 는 데이터 구조 에 대한 읽 기 동작 횟수 가 쓰기 동작 보다 많은 경우 에 가장 적합 하 다. 읽 기 모드 가 잠 겨 있 을 때 공유 할 수 있 고 쓰기 모드 가 잠 겨 있 을 때 특정한 스 레 드 만 자원 을 독점 할 수 있 기 때문에 읽 기와 쓰기 자 물 쇠 를 공유 - 독점 자물쇠 라 고 할 수 있다.
    독자 - 쓰기 자 문 제 를 처리 하 는 두 가지 흔 한 전략 은 강 한 독자 동기 화 (strong reader synchronization) 와 강 한 쓰기 자 동기 화 (strong writer synchronization) 이다.    강 한 독자 동기 화 에서 독자 에 게 더욱 높 은 우선권 을 주 고 작성 자가 현재 쓰기 조작 을 하지 않 으 면 독 자 는 방문 권한 을 얻 을 수 있다.한편, 강 작성 자 동기 화 에서 우선권 을 작성 자 에 게 맡 기 고 독 자 는 기다 리 고 있 거나 실행 중인 작성 자가 끝 난 후에 야 집행 할 수 있다.독자 - 작성 자 모델 에 대해 독자 들 은 최신 정보 기록 을 조회 하 라 고 요구 하기 때문에 항공 편 예약 시스템 은 강 한 작성 자 동기 화 전략 을 사용 하고 도서관 조회 시스템 은 강 한 독자 동기 화 전략 을 사용한다.
    읽 기와 쓰기 잠 금 체 제 는 poix 가 제공 하 는 것 입 니 다. 만약 에 작성 자가 읽 기와 쓰기 자 물 쇠 를 가지 고 있 지 않 으 면 모든 독자 들 이 이 자 물 쇠 를 가지 고 있 을 수 있 습 니 다. 만약 에 어떤 작성 자가 자 물 쇠 를 막 을 때 poix 시스템 에서 독자 가 이 자 물 쇠 를 가 져 올 수 있 는 지 여 부 를 결정 합 니 다.
Lock 은 전통 적 인 스 레 드 모델 중의 synchronized 방식 보다 대상 을 대상 으로 하고 생활 속 의 자물쇠 와 유사 하 며 자물쇠 자체 도 하나의 대상 이 어야 한다.두 스 레 드 에서 실 행 된 코드 세 션 은 동기 화 된 상호 배척 효 과 를 실현 하려 면 같은 Lock 대상 을 사용 해 야 합 니 다.
읽 기와 쓰기 자물쇠: 읽 기와 쓰기 자물쇠 로 나 뉘 는데 여러 개의 읽 기 자 물 쇠 는 서로 배척 하지 않 고 읽 기와 쓰기 자 물 쇠 는 서로 배척 합 니 다. 이것 은 jvm 이 스스로 제어 하 는 것 입 니 다. 당신 은 해당 하 는 자 물 쇠 를 잘 채 우 면 됩 니 다.코드 가 데이터 만 읽 으 면 많은 사람들 이 동시에 읽 을 수 있 지만 동시에 쓸 수 없다 면 자 물 쇠 를 읽 으 세 요.코드 가 데 이 터 를 수정 하면 한 사람 만 쓸 수 있 고 동시에 읽 을 수 없다 면 자 물 쇠 를 쓰 세 요.아무튼 읽 을 때 는 자 물 쇠 를 읽 고 쓸 때 는 자 물 쇠 를 쓴다!
ReentrantReadWriteLock 은 두 개의 자 물 쇠 를 사용 하여 문 제 를 해결 합 니 다. 하 나 는 자 물 쇠 를 읽 고 하 나 는 자 물 쇠 를 읽 는 전제조건 에 들 어 갑 니 다.    다른 스 레 드 의 자물쇠 가 없습니다.    요청 을 쓰 지 않 았 거나 쓰기 요청 이 있 었 지만, 호출 스 레 드 와 자 물 쇠 를 가 진 스 레 드 는 같은 스 레 드 가 자 물 쇠 를 쓰 는 전제조건 입 니 다.    다른 스 레 드 의 읽 기 자물쇠 가 없습니다.    다른 스 레 드 의 잠 금 이 없습니다.
ReentrantReadWriteLock 까지 먼저 해 야 할 일 은 ReentrantLock 과 경 계 를 긋 는 것 입 니 다.그것 과 후 자 는 모두 단독 적 으로 실현 되 고 서로 계승 하거나 실현 하 는 관계 가 없다.그 다음 에 이 자물쇠 메커니즘 의 특성 을 정리 했다.      (a). 내부 에 다시 들 어 가 는 WriteLock 은 ReadLock 을 가 져 올 수 있 지만 반대로 ReadLock 은 WriteLock 을 가 져 오 려 면 영원히 생각 하지 마 세 요.      (b). WriteLock 은 ReadLock 으로 강등 할 수 있 습 니 다. 순 서 는 WriteLock 을 먼저 얻 은 다음 에 ReadLock 을 얻 은 다음 에 WriteLock 을 방출 합 니 다. 이 때 스 레 드 는 Readlock 의 보 유 를 유지 합 니 다.반대로 ReadLock 이 Write Lock 으로 업그레이드 하려 면 불가능 합 니 다. 왜 요?참조 (a), 하하.      (c). ReadLock 은 여러 스 레 드 에 의 해 소유 되 고 역할 을 할 때 모든 WriteLock 을 배척 할 수 있 으 며, WriteLock 은 완전히 상호 배척 된다.이 특성 은 가장 중요 하 다. 높 은 읽 기 주파수 에 비해 상대 적 으로 낮은 기록 데이터 구조 이기 때문에 이러한 잠 금 동기 화 체 제 를 사용 하면 병발 량 을 높 일 수 있다.      (d). ReadLock 이 든 Write Lock 이 든 모두 Interrupt 을 지원 합 니 다. 의 미 는 ReentrantLock 과 일치 합 니 다.      (e). WriteLock 은 Condition 을 지원 하고 ReentrantLock 의 의미 와 일치 하 며, ReadLock 은 Condition 을 사용 할 수 없습니다. 그렇지 않 으 면 Unsupported Operation Exception 이상 을 던 집 니 다.
회전:http://blog.chinaunix.net/uid-27177626-id-3791049.html
http://www.cnblogs.com/liuling/archive/2013/08/21/2013-8-21-03.html