답변:
나는 이것이 재미 있고 적절한 비유가 될 것이라고 생각했기 때문에이 대답을 적었습니다.
잠글 수있는 물건을 교사 (작가)와 많은 학생 (독자)이 있는 교실에서 칠판 (잠글 수 있음) 으로 생각하십시오 .
교사가 칠판에 무언가 (독점 잠금)를 쓰는 동안 :
아직 작성 중이기 때문에 아무도 읽을 수 없으며 그녀가보기를 차단하고 있기 때문입니다. => 개체가 독점적으로 잠겨 있으면 공유 잠금을 얻을 수 없습니다 .
다른 선생님들도 올라 와서 쓰기를 시작하지 않거나 보드를 읽을 수 없게되어 학생들을 혼란스럽게합니다 => 객체가 독점적으로 잠겨 있으면 다른 독점 잠금을 얻을 수 없습니다 .
학생들이 칠판에있는 내용을 읽을 때 (공유 잠금) :
그들은 모두 그 위에있는 것을 읽을 수 있으며, 함께 => 여러 공유 잠금이 공존 할 수 있습니다 .
교사는 더 많은 것을 쓰기 위해 게시판을 지우기 전에 읽기가 끝날 때까지 기다립니다 => 하나 이상의 공유 잠금이 이미 존재하면 독점 잠금을 얻을 수 없습니다 .
lock()호출을 의미합니다. 첫 번째는 즉시 성공적으로 반환됩니다. 즉, 이미 소유 한 것을 성공적으로 잠글 수 있습니다.
writer기다리는 독자보다 우선 될 때 잠금을 가져옵니다 잠금이 선택하는 다음 (가 현재 소유자가 잠금 해제 된 경우). 이것은 정책 에 관한 것 입니다.
매우 간단합니다. 읽기 잠금은 둘 이상의 프로세스가 동시에 읽을 수 있으므로 공유 잠금이라고도합니다. 읽기 잠금의 요점은 다른 프로세스에 의한 쓰기 잠금 획득을 방지하는 것입니다. 대조적으로 쓰기 잠금은 쓰기 작업이 완료되는 동안 다른 모든 작업을 금지하므로 배타적이라고 설명됩니다.
따라서 읽기 잠금은 "지금 읽을 수 있지만 쓰려면 기다려야합니다"라고 말하는 반면 쓰기 잠금은 "기다려야합니다"라고 말합니다.
연구를 지원하기 위해 연구하고 있다는 것을 알고 있지만 강의하려는 충동을 참을 수는 없습니다.
무능한 잠금 사용은 성능 문제의 주요 원인입니다. 읽기 및 쓰기 잠금을 구분하는 잠금 시스템을 사용하는 것이 좋은 시작이지만 신중하게 설계하면 잠금의 필요성을 상당 부분 제거 할 수 있습니다. 예를 들어 세션 상태는 상태 요소 당 하나의 전역 컬렉션에 보관 되어서는 안됩니다 .
나는 실제로 이것을 보았다. 이것은 끔찍한 디자인으로, 세션 상태가 마지막으로 변경 될 때마다 박싱과 컬렉션 변경을 유발하여 오래 쓰기 잠금을 수반합니다. 오버 헤드가 심각하여 서버를 단일 스레드 동작으로 효과적으로 줄였습니다.
모든 세션 상태를 구조체로 집계하는 것만으로도 크게 향상되었습니다. 세션 상태를 변경하면 세션 상태 구조체의 멤버 값만 변경되었습니다. 다른 세션에는 세션의 상태를 직접 참조 할 기회 나 기회가 없었기 때문에 업데이트되는 유일한 컬렉션은 세션 목록이었습니다. 그 결과, 잠금은 완전히 불필요 시 에만 시작과 끝에서, sesssion 및 처리량은 3000 배 증가했다.
다른 일반적인 잠금 시나리오는 사용자 응용 프로그램의 스레드간에 공유되는 리소스입니다. 대부분의 최신 프레임 워크는 잠금 대신 메시지를 사용하여이를 해결합니다. "UI 스레드로 전환"할 때 실제로 함수 포인터와 일부 매개 변수 (또는 구현에 따라 델리게이트 및 스택 프레임)가 포함 된 메시지를 대기열에 넣습니다.
독점 또는 쓰기 잠금은 파일의 지정된 부분에 쓰기위한 독점 액세스 권한을 프로세스에 제공합니다. 쓰기 잠금이 설정된 동안에는 다른 프로세스가 파일의 해당 부분을 잠글 수 없습니다.
공유 또는 읽기 잠금은 다른 프로세스가 파일의 지정된 부분에 대한 쓰기 잠금을 요청하는 것을 금지합니다. 그러나 다른 프로세스는 읽기 잠금을 요청할 수 있습니다.
더 많은 정보 : http://www.gnu.org/software/libc/manual/html_node/File-Locks.html
데이터베이스 측면에서도 동일한 원리입니다. Oracle 문서에 따라
배타적 잠금 모드는 관련 리소스가 공유되지 않도록합니다. 이 잠금 모드는 데이터를 수정하기 위해 획득됩니다. 자원을 독점적으로 잠그는 첫 번째 트랜잭션은 독점 잠금이 해제 될 때까지 자원을 변경할 수있는 유일한 트랜잭션입니다.
공유 잠금 모드에서는 관련된 작업에 따라 관련 리소스를 공유 할 수 있습니다. 데이터를 읽는 여러 사용자가 데이터를 공유하고 공유 잠금을 유지하여 작성자 (배타적 잠금이 필요한 사람)의 동시 액세스를 방지 할 수 있습니다. 여러 트랜잭션
이 동일한 리소스에 대한 공유 잠금을 획득 할 수 있습니다 .