QNX RTOS: 1-7. Shared Objects

Shared Object는 컴파일 시점이 아니라, 프로세스가 실행되는 런타임(Run-time)에 프로세스 내부로 반입되는 코드를 말함. 정적 라이브러리(Static Library)가 실행 파일 안에 완전히 포함되는 것과는 대조적임.

 

1. 두 가지 로딩 방식

Shared Object를 프로세스에 가져오는 방법은 크게 두 가지가 있음.

1.1. 링킹 시점의 의존성 해결 (Implicit Linking)

• 프로그램 빌드 시 -l 옵션 등을 사용해 libc.so나 lib-tcpip.so 같은 라이브러리를 링크함.
• 이 경우, 컴파일된 프로그램 파일 헤더에 "이 프로그램이 실행될 때 이 라이브러리들도 같이 로딩해줘"라는 정보가 기록됨.
• 시스템 로더(Loader)가 프로세스를 생성할 때, 이 정보들을 보고 자동으로 해당 라이브러리 코드를 메모리로 가져옴.

1.2. 명시적 로딩 (Explicit Loading)

• 코드 내부에서 필요할 때 직접 함수를 호출해 라이브러리를 로드함. 흔히 DLL(Dynamic Link Library) 방식이라 부르는 형태임.
• dlopen(): 라이브러리 파일을 염.
• dlsym(): 라이브러리 내부의 함수 심볼 주소를 찾음.
• 이 방식은 플러그인 시스템을 만들거나, 필요할 때만 메모리를 쓰고 싶을 때 유용함.

2. 메모리 효율성: One Copy 전략

Shared Object를 사용하는 가장 큰 이유는 시스템 메모리 절약임.

• 만약 5개의 프로그램이 libc.so를 사용한다고 해서, 물리 메모리에 libc.so가 5개 올라가는 것이 아님.
• 물리 메모리(System Memory)에는 단 하나의 사본만 로드됨.
• 각 프로세스의 가상 주소 공간에는 이 물리 메모리 영역이 Read-Only로 매핑됨.
• 즉, 코드는 공유하되 누구도 그 코드를 수정할 수는 없게 하여 안전성을 확보함.

3. 핵심 주의사항: 데이터의 독립성 (Process Private)

임베디드 개발자들이 가장 자주 착각하여 버그를 만드는 지점이 바로 여기임.

"라이브러리 코드가 공유되니까, 라이브러리 안에 선언된 전역 변수(Global Data)도 프로세스끼리 공유되겠지?" -> 절대 아님.

• 코드(Text Section): 공유됨 (Read-Only).
• 데이터(Data Section): 각 프로세스마다 별도의 사본을 가짐 (Process Private).

예를 들어, Shared Object 안에 int count = 0;이라는 전역 변수가 있다고 가정해보자. 프로세스 A가 count를 10으로 바꿔도, 프로세스 B에서 보이는 count는 여전히 0임. 각 프로세스는 자신만의 데이터 영역을 가지고 있기 때문임.

해결책: 명시적 데이터 공유

만약 프로세스 간에 데이터를 정말로 공유해야 한다면, Shared Object의 변수를 이용하는 것이 아니라, 앞선 챕터나 OS 기능인 Shared Memory(공유 메모리) 객체를 명시적으로 생성해서 사용해야 함.

---

요약

1. Shared Object는 런타임에 로드되는 코드이며, 시스템 로더가 자동으로 가져오거나 개발자가 dlopen으로 직접 가져올 수 있음.
2. 물리 메모리에는 단 한 카피만 존재하며 여러 프로세스가 이를 공유해 메모리를 절약함.
3. 코드는 공유되지만, 라이브러리 내부의 데이터(변수)는 프로세스마다 독립적임. 데이터 공유를 원하면 별도의 IPC(공유 메모리 등)를 써야 함.