공유 라이브러리

Shared library
"공유 개체"는 여기로 리디렉션됩니다.동기화 메커니즘에 대해서는 모니터(동기화)를 참조하십시오.

공유 라이브러리 또는 공유 개체는 실행 파일 및 추가로 공유된 개체 파일에 의해 공유되도록 의도된 파일입니다.프로그램에서 사용되는 모듈은 프로그램에 대한 단일 단일 실행 파일을 생성할 때 링커에 의해 복사되지 않고 로드 시간이나 런타임에 개별 공유 개체에서 메모리로 로드됩니다.

공유 라이브러리는 컴파일 시간 동안 정적으로 연결될 수 있습니다. 즉, 라이브러리 모듈에 대한 참조가 해결되고 실행 파일이 [citation needed]생성될 때 모듈에 메모리가 할당됩니다.그러나 종종 공유 라이브러리의 링크는 [dubious – discuss]로드될 때까지 연기됩니다.

대부분의 최신 운영[NB 1] 체제는 실행 파일과 동일한 형식의 공유 라이브러리 파일을 가질 수 있습니다.이것은 두 가지 주요 이점을 제공합니다. 첫째, 두 가지 모두에 대해 두 가지 로더가 아닌 한 개의 로더만 만들어야 합니다(단일 로더를 사용하는 것은 [citation needed]복잡성을 더할 가치가 있는 것으로 간주됨).둘째, 심볼 테이블이 있는 경우 실행 파일을 공유 라이브러리로도 사용할 수 있습니다.일반적으로 실행 파일과 공유 라이브러리를 결합한 형식은 ELF와 마하-O(유닉스 모두 포함), PE(윈도우즈)입니다.

HP 3000용 16비트 Windows 또는 MPE와 같은 일부 오래된 환경에서는 스택 기반 데이터(로컬)만 공유 라이브러리 코드에 허용되거나 기타 중요한 제한 사항이 공유 라이브러리 코드에 적용되었습니다.

메모리 공유

주요 기사:공유메모리

라이브러리 코드는 여러 프로세스에 의해 메모리와 디스크에서 공유될 수 있습니다.가상 메모리를 사용하는 경우 프로세스는 프로세스의 서로 다른 주소 공간에 매핑된 동일한 물리적 RAM 페이지를 실행합니다.이것은 장점이 있습니다.예를 들어, OpenStep 시스템에서 애플리케이션은 크기가 수백 킬로바이트에 불과하고 빠르게 로드되는 경우가 많았습니다. 대부분의 코드는 운영 [citation needed]체제에서 이미 다른 용도로 로드된 라이브러리에 있었습니다.

프로그램은 유닉스처럼 위치에 구애받지 않는 코드를 사용함으로써 RAM 공유를 달성할 수 있습니다. 이 코드를 통해 복잡하지만 유연한 아키텍처를 구현하거나 Windows 및 OS/2처럼 공통 가상 주소를 사용할 수 있습니다.이러한 시스템은 주소 공간을 미리 매핑하고 각 공유 라이브러리에 슬롯을 예약하는 등 다양한 방법을 통해 코드가 공유될 가능성이 높음을 보장합니다.세 번째 대안은 IBM System/38과 그 후속 제품이 사용하는 단일 레벨 스토어입니다.이를 통해 위치에 따라 코드를 배치할 수 있지만 코드를 어디에 배치할 수 있는지 또는 코드를 공유할 수 있는 방법에 큰 제한을 두지 않습니다.

경우에 따라 다른 버전의 공유 라이브러리가 문제를 일으킬 수 있으며, 특히 버전이 다른 라이브러리의 파일 이름이 동일하고 시스템에 설치된 응용 프로그램이 각각 특정 버전을 필요로 하는 경우에는 더욱 그렇습니다.이러한 시나리오는 윈도우즈 및 OS/2 DLL 파일의 이름을 따서 DLL hell이라고 합니다.2001년 이후의 대부분의 최신 운영 체제는 이러한 상황을 제거하거나 애플리케이션별 "프라이빗"[1] 라이브러리를 사용하는 클린업 방식을 채택하고 있습니다.

동적 링크

주요 기사:다이나믹 링커

동적 링크 또는 지연 바인딩은 실행 파일이 생성될 때가 아니라 프로그램이 로드(로드 시간)되거나 실행(런타임)되는 동안 수행되는 링크입니다.동적 링크 라이브러리(Windows 및 OS/2에서 동적 링크 라이브러리 또는 DLL, OpenVMS에서 [2]공유 가능 이미지, 유닉스 계열 시스템에서 동적 공유 객체 또는 DSO)는 동적 링크를 위한 라이브러리입니다.실행 파일이 생성될 때 링커는 최소한의 작업만을 수행하며, 프로그램이 필요로 하는 라이브러리 루틴과 라이브러리의 루틴의 인덱스 이름 또는 숫자만 기록합니다.대부분의 링크 작업은 응용 프로그램이 로드되는 시간(로드 시간) 또는 실행되는 시간(런타임)에 수행됩니다.일반적으로 "동적 연결기" 또는 "연결 로더"라고 불리는 필요한 연결 프로그램은 실제로 기본 운영 체제의 일부입니다.(그러나 동적 링크를 지원하지 않는 운영 체제의 경우에도 동적 링크를 사용하고 자체 동적 링크기를 포함하는 프로그램을 작성하는 것은 매우 어려울 뿐만 아니라 가능합니다.)

프로그래머들은 원래 1964년부터 멀틱스 운영 체제와 1960년대 [3]후반에 구축된 MTS(Michigan Terminal System)에서 동적 링크를 개발했습니다.

최적화

대부분의 시스템에서 공유 라이브러리는 자주 변경되지 않으므로 시스템은 필요하기 전에 시스템의 각 공유 라이브러리에 대해 가능한 로드 주소를 계산하고 해당 정보를 라이브러리와 실행 파일에 저장할 수 있습니다.로드되는 모든 공유 라이브러리가 이 프로세스를 거쳤다면, 각 라이브러리는 미리 지정된 주소로 로드되므로 동적 연결 프로세스가 빨라집니다.이러한 최적화는 macOS와 Linux에서 각각 사전 바인딩 또는 프리링크로 알려져 있습니다.IBM z/VM은 DCSS([4]Discontinuous Saved Segments)라는 유사한 기술을 사용합니다.이 기술의 단점은 공유 라이브러리가 변경될 때마다 이러한 주소를 미리 계산하는 데 필요한 시간, 주소 공간 레이아웃 랜덤화를 사용할 수 없는 점, 그리고 사용하기에 충분한 가상 주소 공간이 필요한 점(64-비트 아키텍처의 채택으로 인해 완화될 문제,적어도 당분간은)

런타임에 라이브러리 찾기

공유 라이브러리용 로더는 기능 면에서 매우 다양합니다.일부는 라이브러리에 대한 명시적 경로를 저장하는 실행 파일에 의존합니다.라이브러리 이름을 변경하거나 파일 시스템의 레이아웃을 변경하면 이러한 시스템에 장애가 발생합니다.일반적으로 실행 파일에는 라이브러리의 이름만 저장되고 경로는 저장되지 않으며 운영 체제는 일부 알고리즘에 따라 디스크에서 라이브러리를 찾을 수 있는 방법을 제공합니다.

실행 파일이 종속되는 공유 라이브러리를 삭제, 이동 또는 이름 변경하거나 호환되지 않는 버전의 라이브러리를 검색 이전의 위치에 복사하면 실행 파일이 로드되지 않습니다.많은 플랫폼에 존재하는 의존성 지옥이라고 합니다.(유명하지 않은) 윈도우 변형은 흔히 DLL hell이라고 알려져 있습니다.각 라이브러리의 각 버전이 고유하게 식별되고 각 프로그램이 전체 고유 식별자만으로 라이브러리를 참조하는 경우에는 이 문제가 발생할 수 없습니다.이전 윈도우 버전의 "DLL 지옥" 문제는 프로그램의 동적 링크를 해결하기 위해 고유성이 보장되지 않은 라이브러리의 이름만 사용하는 것에서 비롯되었습니다.(DLL hell을 피하기 위해, 윈도우의 후기 버전들은 공유 시스템 DLL을 이전 버전들로 대체하는 것을 방지하기 위한 메커니즘과 함께 개인 DLL을 설치하는 프로그램 옵션들에 주로 의존합니다.)

마이크로소프트 윈도우

Microsoft Windows는 레지스트리를 확인하여 COM 개체를 구현하는 DLL을 로드할 적절한 위치를 결정하지만 다른 DLL의 경우 정의된 순서대로 디렉토리를 확인합니다.먼저 Windows(윈도우)는 프로그램을 로드한 디렉토리(개인[1] DLL)를 확인합니다.SetDllDirectory()함수, System32, System 및 Windows 디렉토리, 현재 작업 디렉토리, 마지막으로 PATH 환경 [5]변수에 의해 지정된 디렉토리.에 대해 작성된 응용 프로그램.NET Framework(2002년 이후) 또한 공유 dll 파일의 주 저장소로 Global Assembly Cache를 확인하여 DLL hell 문제를 제거합니다.

오픈스텝

OpenStep은 시스템을 처음 시작할 때 알려진 다수의 위치(PATH 개념과 유사)에서 라이브러리 목록을 수집하는 보다 유연한 시스템을 사용했습니다.사용자가 시스템을 처음 시작할 때 시간 비용이 발생하지만 라이브러리를 이동하면 전혀 문제가 발생하지 않습니다.

유닉스 계열의 시스템

대부분의 유닉스 계열 시스템에는 동적 라이브러리를 찾는 파일 시스템 디렉토리를 지정하는 "검색 경로"가 있습니다.일부 시스템은 기본 경로를 구성 파일에 지정하고 다른 시스템은 동적 로더에 하드 코드화합니다.일부 실행 파일 형식은 특정 프로그램의 라이브러리를 검색할 추가 디렉토리를 지정할 수 있습니다.일반적으로 setuid 및 setgid 프로그램의 경우 사용할 수 없지만 환경 변수로 재정의될 수 있으므로 사용자는 이러한 프로그램이 루트 권한으로 임의 코드를 실행하도록 강제할 수 있습니다.라이브러리 개발자는 동적 라이브러리를 기본 검색 경로의 위치에 배치하는 것이 좋습니다.단점으로는 새 라이브러리를 설치하는 것이 문제가 될 수 있으며, 이러한 "알려진" 위치는 빠르게 증가하는 라이브러리 파일의 본거지가 되어 관리가 더욱 복잡해집니다.

동적하중

주요 기사:동적하중

동적 링크의 하위 집합인 동적 로드는 요청 시 런타임에 동적으로 연결된 라이브러리 로드 및 언로딩을 포함합니다.이러한 요청은 암묵적으로 또는 명시적으로 이루어질 수 있습니다.암묵적인 요청은 컴파일러나 정적 링커가 파일 경로나 단순히 [citation needed]파일 이름을 포함하는 라이브러리 참조를 추가할 때 이루어집니다.응용 프로그램이 운영 체제의 API로 직접 호출할 때 명시적인 요청이 이루어집니다.

동적으로 연결된 라이브러리를 지원하는 대부분의 운영 체제는 런타임 링커 API를 통해 이러한 라이브러리를 동적으로 로드하는 것도 지원합니다.예를 들어 마이크로소프트 윈도우는 API 기능을 사용합니다.LoadLibrary,LoadLibraryEx,FreeLibrary그리고.GetProcAddressMicrosoft Dynamic Link Libraries와 함께; 대부분의 UNIX 및 UNIX 유사 시스템을 포함한 POSIX 기반 시스템은dlopen,dlclose그리고.dlsym. 일부 개발 시스템은 이 프로세스를 자동화합니다.

메모들

  1. ^ 일부 오래된 시스템(예: Burroughs MCP, Multics)에는 파일 공유 여부에 관계없이 실행 파일에 대한 단일 형식만 있습니다.

추가열람

참고문헌

  1. ^ a b Anderson, Rick (2000-01-11). "The End of DLL Hell". microsoft.com. Archived from the original on 2001-06-05. Retrieved 2012-01-15. Private DLLs are DLLs that are installed with a specific application and used only by that application.
  2. ^ "VSI OpenVMS Linker Utility Manual" (PDF). VSI. August 2019. Retrieved 2021-01-31.
  3. ^ "A History of MTS". Information Technology Digest. 5 (5).
  4. ^ IBM Corporation (2011). Saved Segments Planning and Administration (PDF). Retrieved Jan 29, 2022.
  5. ^ "Dynamic-Link Library Search Order". Microsoft Developer Network Library. Microsoft. 2012-03-06. Archived from the original on 9 May 2012. Retrieved 2012-05-20.