범용 공유 자원 잠금 기술 - 무리가 해결책인가?

범용 공유 자원 잠금 기술 - 무리가 해결책인가?

여러 프로세스가 리소스 집합을 공유하고 "특수" 프로세스가 리소스 집합에 독점적으로 액세스할 수 있도록 잠금 체계를 구현해야 합니다.

이는 일괄 프로세스입니다. 각 트랜잭션이 시작될 때 무한 루프에서 적절한 잠금을 획득하고 마지막에 잠금을 해제하는 것이 좋습니다.

flock필요한 의미(LOCK_SH, LOCK_EX, LOCK_UN)가 있습니다. 나는 Perl Flock.pm과 유일한 목적이 flock"편집"되는 더미 파일을 실험했습니다. 나는 그것이 얼마나 느린지에 대해 조금 놀랐고, 시간이 소비되는 "상단"에서는 분명하지 않습니다. (실행되는 루프에 LOCK_SH 및 LOCK_UN만 포함되어 있어도 CPU 바운드는 아닙니다.) 성급한 최적화를 범하고 싶지는 않지만 flock공유 및 공유를 관리하는 표준 방법이 독점인지 알고 싶습니다. 공유 리소스가 실제 파일이 아니거나 내가 알지 못하는 다른 기능이 있는 경우에도 *nix 액세스의 공유 리소스입니다.

고쳐 쓰다:@msw는 내가 (실수로) 로컬 파일 대신 NFS 파일을 잠근 것으로 정확하게 추측했습니다. 로컬 파일을 사용하면 성능에 미치는 영향이 완전히 제거됩니다. 파일 잠금이 실제로 이러한 유형의 문제를 해결하는 가장 좋은 방법인지 자세히 알아보기 위해 이 질문을 열어 두겠습니다.

답변1

유닉스에는 많은 수의 잠금 시스템이 있습니다. 당신이 찾은 것은 BSD 파일 잠금이라고 하는데,다른파일 잠금 방법. 게다가 당신은 또한신호,뮤텍스그리고 더.

귀하의 직접적인 질문에 관해서는 그렇습니다. 그것은 매우 좋은 접근 방식입니다. 소요되는 시간은 걱정하지 마세요. 본질적으로 잠금은 비용이 많이 드는 활동입니다. 그래서 디자인에 많은 노력을 쏟는다.자물쇠 없음기구.

당신의 계획에 대해 나를 짜증나게 하는 유일한 점은 당신이 만들어야 하는 더미 파일입니다. 원하는 것을 달성하는 더 쉬운 방법이 있을 수 있습니다 mkdir(2). 호출은 원자성이므로 디렉터리가 이미 존재하면 오류가 발생합니다. 대조적으로, open(2)그것은오직 원자O_EXCL, 이는 모든 곳에서 사용할 수 없습니다. 사용 가능한 경우 NFSv2를 사용 중이거나 활성화하지 않았기 때문에 예상대로 작동하지 않을 수 있습니다.NFS 파일 잠금 데몬.

이 접근 방식의 한 가지 이점 mkdir은 .shell 스크립트를 통해 수행할 수 있다는 것입니다 mkdir(1). Perl을 사용하고 계신 것으로 보입니다만, 이 경우에는 외부 모듈이 아닌 내장 함수입니다.

또 다른 이점은 특별한 도움 없이 NFS를 통해 작동한다는 것입니다. 디렉터리를 두 번 만들 수는 없습니다.

이 접근 방식의 유일한 문제점 mkdir()은 기존 디렉터리가 사라질 때까지 기다리게 할 방법이 없다는 것입니다. 즉, 차단 잠금 작업이 아닙니다. 잠금을 놓고 경쟁하는 프로세스가 대부분의 시간 동안 휴면 상태가 되도록 타이머로 래핑하는 것이 좋습니다. 각 프로세스가 임의의 시간 동안 기다리도록 하는 것이 좋습니다. 예를 들어 100~200밀리초 사이에서는usleep(3). 이렇게 하면 양식이 생성됩니다.스핀 잠금.

관련 정보