'시스템 프로그래밍'에 해당되는 글 2건

1. 유닉스와 C의 간단한 역사

유닉스는 AT&T의 벨 연구소에서 켄 톰슨이 개발, 어셈블리로 작성

톰슨은 새로운 운영체제를 만들며 트리구조의 파일 시스템, 명령을 해석하는 셸, 파일은 구조화되지 않은 바이트의 흐름의 개념을 MULTICS로부터 끌어옴

조금 뒤에 톰슨의 벨 연구소 동료이자 유닉스 초기 공동 연구자인 데니스 리치가 C 프로그래밍 언어를 설계하고 구현

그 이후 C는 유닉스 커널을 거의 모두 새로운 언어로 재작성할 수 있을 정도로 발달

1판에서 6판까지 유닉스는 여러 차례 발표됐다.

AT&T는 미국 전화 시스템에 대한 정부의 독점 규제에 묶여있었다.

AT&T가 정부와 합의한 조건 때문에 소프트웨어를 팔 수 없었고, 유닉스도 제품으로 팔 수가 없었다.

6판이 나왔을때 AT&T는 최소한의 배포비용만 받고 대학에 사용권을 주었다.

대학은 유닉스를 수정하여 학생들에게 제공

BSD와 시스템 V의 탄생

1979년 유닉스 7판이 발표. 

이 시점부터 유닉스가 BSD와 시스템V라는 두가지 주요 변종으로 갈림

톰슨은 UC버클리에서 방문 교수로 지냄 (UC버클리 졸업 후 교수 된듯)

대학원생과 함께 여러 가지 새로운 기능을 유닉스에 추가

여러가지 새로운 도구와 기능이 버클리에서 개발되었음.

BSD(Berkeley Software Distribution)라는 이름으로, 이버전의 유닉스는 소스코드째 널리 배포

그 이후 4.1 ~ 4.4BSD 버전으로 널리 개발됨

그 사이에 AT&T가 분해됐고, 그 결과 전화 시스템에 대한 독점이 해소되어, 유닉스 판매가 가능

그 이후 시스템 V 발표, 시스템 V는 여러 회사에 사용권이 제공되었고, 여러 회사는 이를 기초로 각자의 유닉스를 구현

따라서 학계에 퍼진 다양한 BSD 배포판뿐만 아니라, 다양한 하드웨어상에 유닉스의 여러가지 상업적 구현이 존재

상업적 구현에는 나중에 솔라리스가 된 썬의 SunOS, IBM의 AIX, 애플 매킨토시의 A/UX, 마이크로소프트와 SCO의 XENIX가 포함

2. 리눅스의 간략한 역사

2.1 GNU 프로젝트

MIT에서 일하던 리처드 스톨만은 자유(FREE) 유닉스 구현을 만들기 시작

커널과 모든 관련 소프트웨어 패키지로 이뤄진, 완전하고 자유롭게 구할 수 있는 유닉스와 유사한 시스템을 개발하기 위해 GNU 프로젝트(GNU IS NOT UNIX)를 시작 (재귀적 의미)

GNU프로젝트의 중요 결과 중 하나는 자유 소프트웨어 개념을 법적으로 구체화한 GPL(General Public License)다.

GPL License: 반드시 소스 코드를 구할 수 있어야 하고, GPL에 따라 자유롭게 배포할 수 있어야한다.

초기의 GNU프로젝트는 동작하는 유닉스 커널을 만들지 못하고 여러가지 응용 프로그램을 만듦(Emacs 등)

1990년대 초 GNU프로젝트는 유닉스 커널을 제외한 거의 완전한 시스템을 만듦

2.2 리눅스 커널

1991년 핀란드 헬싱키 대학 학생 리누스 토발즈는 유닉스 커널을 만드는 프로젝트를 시작, 몇 달 뒤 토발즈는 여러 가지 GNU 프로그램을 컴파일 하고 실행하는 기본 커널을 개발

토발즈는 리눅스를 GNU GPL에 따라 배포하기 시작

여러 사람들이 함께 개발

3. 표준화

3.1 C 프로그래밍 언어

유닉스 구현의 다양성에 문제가 있었음

BSD에 기반한 유닉스 구현, 시스템 V에 기반한 구현, 어떤 구현은 짬뽕~

다양한 구현들 사이에 차이가 생김

이러한 요인으로 인해 ANSI(American National Standards Institute)의 승인으로 C의 표준화

이 표준은 ISO표준으로 채택

1999년 ISO에 의해 C 표준 개정(C99)

C표준은 운영체제와 독립적이다. 유닉스에 매여있지 않고, C를 제공하는 어떤 컴퓨터와 운영체제에도 이식이 가능

1. IPC 방법의 분류

크게 3개의 기능적 분류로 나눌 수 있음.

• 통신 : 프로세스 간에 데이터를 주고받는 방법

• 동기화: 프로세스나 스레드 간에 동기화를 맞추는 방법

• 시그널: 시그널은 다른목적으로 설계되었지만, 특정 상황에서 동기화를 맞추는 방법으로 사용 가능

  시그널 번호 자체가 하나의 정보 형태기때문에 통신목적으로도 사용 가능(연관된 정수, 포인터를 수반할 수 있음)

2. 통신 방법

• 데이터 전송: 쓰기와 읽기 두가지 요소로 구분
  통신을 하려면 한 프로세스에서 IPC방법에 데이터를 쓰고 다른 프로세스는 이 데이터를 읽어야함
  이 기술에는 사용자 메모리와 커널 메모리 간에 통신하는 두가지 전송 모드가 있음
  - 쓰는 동안 사용자 메모리로부터 커널 메모리로 전송
  - 읽는 동안 커널 메모리에서 사용자 메모리로 전송
• 공유 메모리: 특정 메모리 영역에 데이터를 저장해 프로세스간 데이터를 공유하는 방식
  사용자 메모리와 커널 메모리 사이에 시스템 호출이나 데이터 전송이 필요하지 않기 때문에 공유 메모리는 매우 빠른 통신을 제공

데이터 전송방법은 다음과 같이 하위 카테고리로 더 세분화 할 수 있음

• 바이트 스트림: 파이프, FIFO, 스트림 소켓을 통해 전송되는 데이터는 제한되지 않은 바이트 스트림
  각 read 오퍼레이션은 전송자가 얼마만큼의 데이터를 섰는지에 상관없이 IPC방법으로부터 임의의 크기의 바이트를 읽어야 하는지 얻어와서 읽음
• 메시지: 시스템 V 메시지큐, POSIX 메시지 큐, 소켓 데이터그램은 데이터를 전송할 때 한 번에 전송할 수 있는 크기에 제한이 있음. 각 읽기 오퍼레이션은 송신자의 프로세스가 쓴 데이터 전체를 한번에 읽게됨.
  IPC방법에 메시지의 일부를 놔두고 메시지의 일부분만을 읽을 수 없음
  한번의 읽기 오퍼레이션으로 여러개의 메시지를 읽는것도 불가능
• 가상 터미널: 가상터미널은 통신 방법중 하나이며 특정 상황에서 설계됨. 이건 나중에 더 공부 필요...
  송신자, 수신자 프로세스 간의 동기화는 자동으로 이루어짐. 읽기시 수신한 데이터가 없다면 자동으로 블록

공유 메모리는 시스템 V 공유 메모리, POSIX 공유 메모리, 메모리 매핑 세가지 공유 메모리를 제공

공유 메모리가 빠른 통신 방법을 제공하지만, 이런 속도의 장점은 공유 메모리를 동기화하는 데 들어가는 시간과 상쇄될 수 있음. 하나의 프로세스는 다른 프로세스가 메모리상에서 작업을 하고 있을 때 접근 불가능.

메모리에 저장된 데이터는 같은 메모리를 공유하는 모든 프로세스에서 볼 수 있음.

3. 동기화 방법

세마포어: 리눅스는 시스템 v 세마포어와 POSIX 세마포어를 제공

파일 잠금: 같은 파일에 다중 프로세스가 작업을 할 때 이를 중재

읽기 잠금과 쓰기 잠금으로 사용. flock(), fcntl() 시스템 호출로 제공.

flock()은 전체파일 잠금. 거의 사용하지 않음.

fcntl()으로 레코드 잠금. 파일의 여러곳에 lock할수 있음.

뮤텍스: POSIX 스레드에서 일반적으로 사용

-> 통신 방법을 동기화에 사용할 수 있음. 

4. IPC 방법 비교하기

데이터 전송 방법 vs 공유 메모리

데이터 전송 방법(파이프, FIFO, 메시지)은 동기화를 커널이 자동으로 처리. 여러 응용프로그램 설계에 적합

공유메모리는 하나의 프로세스가 같은 메모리 공간을 공유해 다른 여러 프로세스에서 데이터를 볼수있게 할때 유용.

공유메모리는 동기화를 지원해야하므로 복잡한 설계를 추가해야 할 수 있음.

바이트 스트림(파이프, FIFO, 소켓) 전송 vs 메시시 전송(메시지 큐, 데이터그램 소켓)

응용프로그램이 바이트 스트림 방법의 메시지 중심 모델을 선호 할 수 있는데 구분문자를 사용, 고정 길이 메시지를 사용, 최종 메시지 길이를 헤더에 표시 등을 사용할 수 있기 때문

시스템V와 메시지 큐 VS 그밖의 데이터 전송 방법

시스템 V와 메시지 큐는 숫자형이나 우선순위를 메시지에 줄 수 있음. 보낸 순서와 다른순서로 도착 할 수 있음

파이프, FIFO, 소켓은 파일 디스크립터를 통해 구현됨.

I/O 모델의 대안으로 제시된 멀티플렉싱(select()와 poll() 시스템 호출), 시그널 기반 I/O, 리눅스 고유의 epoll API를 모두 지원. 동시에 다중 파일 디스크립터를 관찰해 I/O중 어떤 것이 사용 가능한지 파악 할 수 있음.

시스템 V 메시지 큐는 파일 디스크립터 기술을 사용하지 않고 이런 기술을 지원하지 않음. 

POSIX 메시지큐는 통지 방법을 제공, 프로세스나 새로운 스레드에 비어있는 쿠에 메시지가 도착하면 시그널을 전송

유닉스 도메인 소켓은 파일 디스크립터를 하나의 프로세스에서 다른 프로세스로 전달할 수 있는 기능을 제공

이 기능은 하나의 프로세스에서 파일을 열고 이를 파일에 접근할 수 없는 다른 프로세스가 사용 가능하게 함

레코드 잠금은 fcntl() 을 이용해 걸게됨 fcntl()을 사용할 경우 커널이 데드락을 감지하지만 시스템V와 POSIX 세마포어는 소유권 속성을 갖고있지 않아 세마포어의 데드락을 커널이 자동으로 감지 할 수 없음.

시스템 V IPC 설계 이슈

시스템 V IPC는 전통적인 유닉스 I/O 모델과는 독립적으로 설계됐기 때문에 결과적으로 기이한 프로그래밍 인터페이스가 존재, 사용하기 복잡 //  POSIX IPC는 이런 문제를 고려해 설계됨

시스템 V IPC는 비 연결형 : IPC를 열기 위해 사용하는 핸들 개념을 제공하지 않음. 커널은 프로세스가 객체를 열고있는지 기록하지 않기때문에 객체가 안전하게 제거되는지 알기 위해서는 추가적인 프로그래밍이 필요

출처: 리눅스 API의 모든것 고급 리눅스 API