fcntl, lockf, 파일 잠금에 어떤 것을 사용하는 것이 좋습니까?

fcntl, lockf, 파일 잠금에 어떤 것을 사용하는 것이 좋습니까?

fcntl과 lockf의 장점과 단점에 대한 정보를 찾고 있습니다.예를 들어 휴대성을 위해 어떤 것을 사용하는 것이 좋을까요?현재 Linux 데몬을 코딩하고 있으며 상호 제외를 적용하기 위해 어떤 것이 더 적합한지 고민하고 있습니다.

lockf와 fcntl의 차이점은 무엇입니까?

많은 시스템에서lockf()라이브러리의 루틴은 그저 둘러막기에 불과하다fcntl()즉,lockf에는, 다음과 같은 기능의 서브셋이 있습니다.fcntl한다.

원천

하지만 일부 시스템에서는fcntl그리고.lockf잠금은 완전히 독립적입니다.

원천

구현에 따라 다르므로 항상 동일한 규칙을 사용하십시오.따라서 항상 두 프로세스에서 lockf를 사용하거나 항상 fcntl을 사용하십시오.교환이 가능할 가능성이 높지만, 같은 것을 사용하는 것이 더 안전합니다.

어느 쪽을 선택하든 상관없습니다.

---

필수 잠금과 권고 잠금에 대한 몇 가지 참고 사항:

unix/linux에서의 잠금은 기본적으로 권장 사항입니다. 즉, 다른 프로세스는 설정된 잠금 규칙을 따를 필요가 없습니다.따라서 공동 작업 프로세스에서도 동일한 규칙을 사용하는 한 어떤 방식으로 잠그든 상관 없습니다.

Linux는 필수 잠금을 지원하지만 파일 시스템이 옵션을 켜고 파일 특수 속성을 설정한 상태로 마운트된 경우에만 해당됩니다.사용할 수 있습니다.mount -o mand파일 시스템을 마운트하고 파일 속성을 설정합니다.g-x,g+s필수 잠금을 활성화하려면fcntl또는lockf. 필수 잠금이 작동하는 방법에 대한 자세한 내용은 여기를 참조하십시오.

잠금은 개별 파일이 아니라 inode에 적용됩니다.즉, 동일한 파일 데이터를 가리키는 2개의 파일 이름이 동일한 잠금 상태를 공유합니다.

한편, Windows 에서는, 파일을 배타적으로 열 수 있기 때문에, 다른 프로세스가 파일을 완전하게 열 수 없습니다.그들이 원해도.즉, 자물쇠는 필수 사항입니다.Windows 및 파일 잠금도 마찬가지입니다.적절한 액세스 권한이 있는 열린 파일핸들이 있는 프로세스에서는 파일의 일부를 잠글 수 있으며 다른 프로세스에서는 그 부분에 액세스할 수 없습니다.

---

Linux에서 필수 잠금 기능:

필수 잠금과 관련하여 프로세스가 읽기 잠금으로 파일의 영역을 잠글 경우 다른 프로세스는 읽기만 허용되지만 해당 영역에 쓰기는 허용되지 않습니다.프로세스가 쓰기 잠금으로 파일 영역을 잠글 경우 다른 프로세스는 파일을 읽거나 쓸 수 없습니다.프로세스가 파일의 일부에 액세스 할 수 없는 경우의 동작은, 다음의 지정의 유무에 의해서 다릅니다.O_NONBLOCK그렇지 않으면.블로킹이 설정되어 있는 경우는, 조작을 실행할 때까지 대기합니다.블로킹이 설정되어 있지 않은 경우는, 다음의 에러 코드가 표시됩니다.EAGAIN.

---

NFS 경고:

NFS 마운트에서 잠금 명령을 사용하는 경우 주의하십시오.동작은 정의되어 있지 않으며 구현은 로컬 잠금만 사용할지 또는 원격 잠금을 지원할지 매우 다양합니다.

두 인터페이스 모두 POSIX 표준의 일부이며, 현재는 대부분의 시스템에서 두 인터페이스를 모두 사용할 수 있습니다(Linux, FreeBSD, Mac OS X 및 Solaris를 방금 확인했습니다).따라서 요구 사항에 더 적합한 것을 선택하여 사용하십시오.

주의사항: 한 프로세스가 fcntl을 사용하여 파일을 잠그고 다른 프로세스가 lockf를 사용하여 파일을 잠글 때 어떤 일이 발생할지는 지정되지 않았습니다.대부분의 시스템에서는 동등한 조작(실제로 Linux lockf는 fcntl 위에 구현되어 있습니다)이지만 POSIX에서는 이들 조작이 명시되어 있지 않다고 합니다.따라서 2개의 인터페이스 중 하나를 사용하는 다른 프로세스와 상호 운용하는 경우 동일한 프로세스를 선택합니다.

다른 사람들은 이 잠금장치는 권고 사항일 뿐이며, 지역 잠금 여부를 확인할 책임이 있다고 쓰고 있습니다.또한 잠금 기능을 사용하려면 stdio 기능을 사용하지 마십시오.

이 경우(즉, Linux 데몬을 코드화하여 상호 제외 적용에 어떤 것이 더 적합한지 고민하는 경우) 주요 관심사는 다음과 같습니다.

1. 잠긴 파일이 로컬 파일입니까, 아니면 NFS 파일입니까?
   • 예를 들어 NFS에서 데몬의 pid 파일을 만들고 잠그도록 사용자가 속일 수 있습니까?
2. 이 경우 잠금이 어떻게 작동합니까?fork또는 데몬 프로세스가 극단적으로 손상되어 종료된 경우. kill -9?

그flock그리고.fcntl명령어는 두 경우 모두 다르게 동작합니다.

제가 추천하는 것은fcntlWikipedia의 파일 잠금 문서를 참조하여 두 솔루션 모두 관련된 문제에 대해 자세히 설명합니다.

fcntl과 fcntl 모두 다른 운영체제에서 온 프로그래머를 혼란스럽게 만들 수 있는 특이한 점이 있습니다.NFS 등의 네트워크 파일 시스템에서 flock이 기능하는지 여부는 구현에 따라 달라집니다.BSD 시스템에서는 폴 콜은 정상적으로 no-ops가 됩니다.2.6.12보다 이전 Linux에서는 NFS 파일의 그룹 콜은 로컬에서만 작동합니다.커널 2.6.12 이상에서는 POSIX 바이트 범위 잠금을 사용하여 NFS 파일에 대해 flock 콜을 구현합니다.이러한 잠금은 fcntl()/POSIX 잠금을 구현하는 다른 NFS 클라이언트에서 확인할 수 있습니다.1 잠금 업그레이드 및 다운그레이드는 새 잠금을 적용하기 전에 이전 잠금을 해제합니다.다른 애플리케이션이 배타적 잠금을 기다리는 동안 응용 프로그램이 배타적 잠금을 공유 잠금으로 다운그레이드하면, 후자의 응용 프로그램은 배타적 잠금을 얻고 첫 번째 응용 프로그램은 잠깁니다.특정 프로세스의 파일과 관련된 모든 fcntl 잠금은 해당 파일의 파일 기술자가 해당 프로세스에 의해 닫히면 해당 파일 기술자에 대한 잠금이 요청되지 않았더라도 삭제됩니다.또한 fcntl 잠금은 자 프로세스에 의해 상속되지 않습니다.fcntl close 시멘틱스는 파일에 액세스할 수 있는 서브루틴 라이브러리를 호출하는 어플리케이션에서 특히 문제가 됩니다.

fcntl을 사용하다가 문제가 발생했는데, 어느 용어를 검색해도 양쪽 상단에 이 페이지가 표시되므로 여기에 보고해야 할 것 같습니다.

상기와 같이 BSD 잠금을 권장합니다.OSX(darwin)가 BSD인지 모를 수 있습니다.쓸 파일을 열 때 이 점에 유의해야 합니다.

fcntl/flock을 사용하려면 먼저 파일을 열고 해당 ID를 가져와야 합니다.그러나 "w"로 파일을 열면 파일이 즉시 비워집니다.파일이 다른 곳에서 사용되고 있기 때문에 프로세스가 잠금을 취득할 수 없는 경우 파일이 0kb로 유지되고 반환될 가능성이 높습니다.잠긴 프로세스에서 파일이 아래에서 사라진 것을 발견하면 일반적으로 치명적인 결과가 뒤따릅니다.

이 문제를 해결하려면 파일 잠금을 사용할 때 파일 "w"를 열지 말고 "a"를 열어 첨부하십시오.잠금을 정상적으로 취득하면, 「w」와 같이 파일을 안전하게 클리어 할 수 있습니다.

fseek(fileHandle, 0, SEEK_SET);//처음으로 이동합니다.

ftruncate(fileno((FILE *) fileHandle), 0);// 클리어합니다.

이것은 나에게 불쾌한 수업이었다.

상호 배제를 위해 사용하는 데몬을 코딩하는 것이므로, 결국 데몬은 그 자체와 호환성이 있어야 합니다.

파일 잠금 메커니즘의 비결은 일관성을 유지하는 것입니다. 파일 잠금 메커니즘을 사용하고 그대로 유지하십시오.그것들을 바꾸는 것은 좋지 않은 생각이다.

여기서는 파일 시스템이 로컬 시스템이라고 가정합니다.파일 시스템이 로컬 시스템이 아닌 경우 모든 것이 무효가 됩니다.NFS 또는 기타 네트워크 파일 시스템은 다양한 수준의 유효성으로 잠금을 처리합니다(경우에 따라서는 없음).

언급URL : https://stackoverflow.com/questions/575328/fcntl-lockf-which-is-better-to-use-for-file-locking