Unix에서 파이프라인을 구현하는 방법

이 문서에서는 Unix 커널의 파이프라인 구현에 대해 설명합니다. "라는 제목의 최근 기사에 다소 실망했습니다.Unix에서 파이프라인은 어떻게 작동합니까?" 꺼졌다 아니 내부 구조에 대해 나는 호기심이 생겨 답을 찾기 위해 오래된 출처를 파헤쳤다.

우리가 무슨 소리하는거야?

파이프라인은 "아마도 Unix에서 가장 중요한 발명품"일 것입니다. 작은 프로그램과 친숙한 명령줄 슬로건을 결합하는 Unix의 기본 철학을 정의하는 특징입니다.

$ echo hello | wc -c
6

이 기능은 커널 제공 시스템 호출에 따라 다릅니다. pipe, 설명서 페이지에 설명되어 있습니다. 파이프(7) и 파이프(2):

파이프라인은 프로세스 간 통신을 위한 단방향 채널을 제공합니다. 파이프라인에는 입력(쓰기 끝)과 출력(읽기 끝)이 있습니다. 파이프라인의 입력에 기록된 데이터는 출력에서 ​​읽을 수 있습니다.

파이프라인은 다음을 호출하여 생성됩니다. pipe(2), 두 개의 파일 설명자를 반환합니다. 하나는 파이프라인의 입력을 나타내고 두 번째는 출력을 나타냅니다.

위 명령의 추적 출력은 파이프라인 생성과 이를 통해 한 프로세스에서 다른 프로세스로의 데이터 흐름을 보여줍니다.

$ strace -qf -e execve,pipe,dup2,read,write 
    sh -c 'echo hello | wc -c'

execve("/bin/sh", ["sh", "-c", "echo hello | wc -c"], …)
pipe([3, 4])                            = 0
[pid 2604795] dup2(4, 1)                = 1
[pid 2604795] write(1, "hellon", 6)    = 6
[pid 2604796] dup2(3, 0)                = 0
[pid 2604796] execve("/usr/bin/wc", ["wc", "-c"], …)
[pid 2604796] read(0, "hellon", 16384) = 6
[pid 2604796] write(1, "6n", 2)        = 2

상위 프로세스 호출 pipe()첨부 파일 디스크립터를 가져옵니다. 하나의 하위 프로세스는 하나의 설명자에 쓰고 다른 프로세스는 다른 설명자에서 동일한 데이터를 읽습니다. 쉘은 stdin 및 stdout과 일치하도록 dup2로 설명자 3 및 4를 "이름 변경"합니다.

파이프라인이 없으면 셸은 한 프로세스의 출력을 파일에 쓰고 다른 프로세스로 파이프하여 파일에서 데이터를 읽어야 합니다. 결과적으로 더 많은 리소스와 디스크 공간을 낭비하게 됩니다. 그러나 파이프라인은 임시 파일을 피하는 것 이상으로 유용합니다.

프로세스가 빈 파이프라인에서 읽으려고 하면 read(2) 데이터를 사용할 수 있을 때까지 차단됩니다. 프로세스가 전체 파이프라인에 쓰기를 시도하면 write(2) 쓰기를 완료하기 위해 파이프라인에서 충분한 데이터를 읽을 때까지 차단됩니다.

POSIX 요구 사항과 마찬가지로 이것은 중요한 속성입니다. PIPE_BUF 바이트(최소 512)는 일반 파일(그러한 보장을 제공하지 않음)이 할 수 없는 방식으로 프로세스가 파이프라인을 통해 서로 통신할 수 있도록 원자적이어야 합니다.

일반 파일을 사용하면 프로세스는 모든 출력을 여기에 쓰고 다른 프로세스로 전달할 수 있습니다. 또는 프로세스는 외부 신호 메커니즘(예: 세마포어)을 사용하여 하드 병렬 모드에서 작동하여 쓰기 또는 읽기 완료에 대해 서로에게 알릴 수 있습니다. 컨베이어는 이 모든 번거로움에서 우리를 구해줍니다.

우리는 무엇을 찾고 있습니까?

컨베이어가 어떻게 작동하는지 쉽게 상상할 수 있도록 손가락으로 설명하겠습니다. 메모리에 버퍼와 일부 상태를 할당해야 합니다. 버퍼에서 데이터를 추가하고 제거하는 기능이 필요합니다. 파일 설명자에 대한 읽기 및 쓰기 작업 중에 함수를 호출하려면 일부 기능이 필요합니다. 그리고 위에서 설명한 특수 동작을 구현하려면 잠금이 필요합니다.

우리는 이제 막연한 정신 모델을 확인하거나 반증하기 위해 밝은 램프 아래에서 커널의 소스 코드를 조사할 준비가 되었습니다. 그러나 항상 예상치 못한 상황에 대비하십시오.

우리는 어디를 찾고 있습니까?

나는 그 유명한 책의 사본이 어디에 있는지 모른다.라이온스 북« Unix 6 소스 코드를 사용하지만 덕분에 유닉스 헤리티지 소사이어티 온라인으로 검색 가능 소스 코드 이전 버전의 Unix도 마찬가지입니다.

TUHS 아카이브를 돌아다니는 것은 박물관을 방문하는 것과 같습니다. 우리는 우리의 공유된 역사를 볼 수 있으며 오래된 카세트와 출력물에서 이 모든 자료를 조금씩 복구하려는 수년간의 노력에 경의를 표합니다. 그리고 나는 아직 잃어버린 조각들을 절실히 알고 있습니다.

파이프라인의 고대 역사에 대한 호기심을 만족시키면 비교를 위해 현대 코어를 살펴볼 수 있습니다.

또한, pipe 테이블에서 시스템 호출 번호 42입니다. sysent[]. 우연의 일치?

전통적인 유닉스 커널(1970–1974)

아무 흔적도 못 찾았어 pipe(2) 어느 쪽도 PDP-7 유닉스 (1970년 XNUMX월) 초판 유닉스 (1971년 XNUMX월), 불완전한 소스 코드 두번째 버전 (1972년 XNUMX월).

TUHS는 제XNUMX판 유닉스 (1973년 XNUMX월)은 파이프라인이 포함된 첫 번째 버전입니다.

Unix의 세 번째 에디션은 커널이 어셈블러로 작성된 마지막 버전이자 파이프라인이 있는 첫 번째 버전이기도 합니다. 1973년에 제XNUMX판을 개선하기 위한 작업이 진행 중이었고 커널은 C로 재작성되어 유닉스 제XNUMX판이 탄생했습니다.

한 독자는 Doug McIlroy가 "정원 호스와 같은 연결 프로그램"이라는 아이디어를 제안한 문서 스캔을 발견했습니다.

브라이언 커니건의 책에서유닉스: 역사와 회고록”, 컨베이어 출현의 역사는 또한이 문서를 언급합니다. "... Bell Labs에있는 내 사무실 벽에 30 년 동안 걸려있었습니다." 여기 매킬로이와의 인터뷰그리고 또 다른 이야기 2014년에 작성된 McIlroy의 작업:

Unix가 등장했을 때 코루틴에 대한 나의 열정은 OS 작성자인 Ken Thompson에게 일부 프로세스에 기록된 데이터가 장치뿐만 아니라 다른 프로세스로의 종료에도 허용되도록 요청했습니다. Ken은 그것이 가능하다고 생각했습니다. 그러나 미니멀리스트로서 그는 모든 시스템 기능이 중요한 역할을 하기를 원했습니다. 중간 파일에 쓰는 것보다 프로세스 간 직접 쓰기가 실제로 큰 이점입니까? 그리고 "파이프라인"이라는 눈에 띄는 이름과 프로세스 상호 작용 구문에 대한 설명으로 특정 제안을했을 때만 Ken은 마침내 "내가 할 것입니다! "라고 외쳤습니다.

그리고 그랬다. 어느 운명적인 저녁에 Ken은 커널과 셸을 변경하고 여러 표준 프로그램을 수정하여 입력(파이프라인에서 올 수 있음)을 받아들이는 방법을 표준화하고 파일 이름을 변경했습니다. 다음날 파이프라인은 애플리케이션에서 매우 널리 사용되었습니다. 주말까지 비서들은 문서를 워드 프로세서에서 프린터로 보내는 데 사용했습니다. 얼마 후 Ken은 파이프라인 사용을 랩핑하기 위한 원래 API와 구문을 그 이후로 사용된 더 깔끔한 규칙으로 교체했습니다.

불행하게도 제XNUMX판 유닉스 커널의 소스 코드는 유실되었습니다. C로 작성된 커널 소스 코드가 있지만 제XNUMX판, 1973년 XNUMX월에 출시되었지만 공식 출시 몇 달 전에 나왔고 파이프라인 구현을 포함하지 않습니다. 이 전설적인 Unix 기능의 소스 코드가 아마도 영원히 사라진다는 것은 안타까운 일입니다.

다음에 대한 문서 텍스트가 있습니다. pipe(2) 두 릴리스 모두에서 문서를 검색하여 시작할 수 있습니다. 세 번째 버전 (특정 단어의 경우 "수동으로" 밑줄이 그어져 있고 ^H 문자 뒤에 밑줄이 옵니다!). 이 프로토-pipe(2) 어셈블러로 작성되었으며 하나의 파일 설명자만 반환하지만 이미 예상되는 핵심 기능을 제공합니다.

시스템 호출 파이프 파이프라인이라는 I/O 메커니즘을 생성합니다. 반환된 파일 설명자는 읽기 및 쓰기 작업에 사용할 수 있습니다. 파이프라인에 무언가를 쓰면 최대 504바이트의 데이터를 버퍼링한 후 쓰기 프로세스가 일시 중단됩니다. 파이프라인에서 읽을 때 버퍼링된 데이터를 가져옵니다.

이듬해 커널은 C로 재작성되었고, pipe(2) 제XNUMX판 프로토타입으로 현대적인 모습을 갖추다 "pipe(fildes)»:

시스템 호출 파이프 파이프라인이라는 I/O 메커니즘을 생성합니다. 반환된 파일 설명자는 읽기 및 쓰기 작업에 사용할 수 있습니다. 무언가가 파이프라인에 기록되면 r1(resp. fildes[1])에 반환된 설명자가 사용되며 최대 4096바이트의 데이터를 버퍼링한 후 쓰기 프로세스가 일시 중단됩니다. 파이프라인에서 읽을 때 r0으로 반환된 설명자(각각 fildes[0])가 데이터를 가져옵니다.

일단 파이프라인이 정의되면 두 개(또는 그 이상)의 상호 작용 프로세스(후속 호출에 의해 생성됨)가 포크) 호출을 사용하여 파이프라인에서 데이터를 전달합니다. 읽기 и 쓰다.

셸에는 파이프라인을 통해 연결된 프로세스의 선형 배열을 정의하기 위한 구문이 있습니다.

한쪽 끝만 있는(모든 쓰기 파일 설명자가 닫힘) 비어 있는 파이프라인(버퍼링된 데이터 포함)에서 읽기 호출은 "파일 끝"을 반환합니다. 유사한 상황의 쓰기 호출은 무시됩니다.

가장 이른 보존된 파이프라인 구현 관련 유닉스 XNUMX판까지 (1974년 XNUMX월) 다음 릴리스에 등장한 것과 거의 동일합니다. 주석만 추가되었으므로 XNUMX판은 건너뛸 수 있습니다.

유닉스 1975판(XNUMX)

Unix 소스 코드 읽기 시작 여섯 번째 판 (1975년 XNUMX월). 주로 덕분에 사자 이전 버전의 소스보다 찾기가 훨씬 쉽습니다.

수년 동안 책 사자 Bell Labs 외부에서 사용할 수 있는 Unix 커널에 대한 유일한 문서였습니다. XNUMX판 라이선스에서는 교사가 소스 코드를 사용할 수 있도록 허용했지만 XNUMX판 라이선스에서는 이러한 가능성을 배제하여 불법 타자본으로 배포되었습니다.

오늘 복사기에서 학생들을 묘사하는 책의 재 인쇄 사본을 구입할 수 있습니다. 그리고 TUHS 프로젝트를 시작한 Warren Toomey 덕분에 XNUMX판 원본 PDF. 파일을 만드는 데 얼마나 많은 노력이 들었는지에 대한 아이디어를 제공하고 싶습니다.

15년 전에 저는 사자알려지지 않은 다른 사본의 품질이 마음에 들지 않았기 때문입니다. TUHS는 아직 존재하지 않았고 이전 소스에 액세스할 수 없었습니다. 그러나 1988년에 PDP9 컴퓨터에서 백업한 11개 트랙이 있는 오래된 테이프를 발견했습니다. 작동 여부를 알기는 어려웠지만 대부분의 파일이 1979년으로 표시되어 있는 온전한 /usr/src/ 트리가 있었는데 당시에도 오래된 것으로 보였습니다. 일곱 번째 판 또는 PWB 파생물이라고 생각했습니다.

나는 발견을 기초로 삼아 출처를 여섯 번째 판의 상태로 수동으로 편집했습니다. 코드의 일부는 동일하게 유지되었고 일부는 약간 편집하여 최신 토큰 +=을 구식 =+로 변경해야 했습니다. 어떤 것은 단순히 삭제되었고 어떤 것은 완전히 다시 작성되어야 했지만 너무 많지는 않았습니다.

그리고 오늘 우리는 TUHS에서 XNUMX판의 소스 코드를 온라인으로 읽을 수 있습니다. Dennis Ritchie가 손을 잡은 아카이브.

그런데 언뜻 보기에 커니건과 리치 시대 이전의 C 코드의 주요 특징은 간결. 내 사이트의 상대적으로 좁은 표시 영역에 맞게 광범위한 편집 없이 코드 스니펫을 삽입할 수 있는 경우는 드뭅니다.

초기의 /usr/sys/ken/pipe.c 설명이 있습니다(예, 더 있습니다. /usr/sys/dmr):

/*
 * Max allowable buffering per pipe.
 * This is also the max size of the
 * file created to implement the pipe.
 * If this size is bigger than 4096,
 * pipes will be implemented in LARG
 * files, which is probably not good.
 */
#define    PIPSIZ    4096

버퍼 크기는 XNUMX판 이후로 변경되지 않았습니다. 그러나 여기에서는 공개 문서 없이 파이프라인이 한때 파일을 대체 스토리지로 사용했음을 알 수 있습니다!

LARG 파일은 다음에 해당합니다. 아이노드 플래그 LARG, "대형 주소 지정 알고리즘"에서 처리하는 데 사용됩니다. 간접 차단 더 큰 파일 시스템을 지원합니다. Ken이 그것들을 사용하지 않는 것이 낫다고 말했기 때문에 나는 그의 말을 받아들이게 되어 기쁩니다.

다음은 실제 시스템 호출입니다. pipe:

/*
 * The sys-pipe entry.
 * Allocate an inode on the root device.
 * Allocate 2 file structures.
 * Put it all together with flags.
 */
pipe()
{
    register *ip, *rf, *wf;
    int r;

    ip = ialloc(rootdev);
    if(ip == NULL)
        return;
    rf = falloc();
    if(rf == NULL) {
        iput(ip);
        return;
    }
    r = u.u_ar0[R0];
    wf = falloc();
    if(wf == NULL) {
        rf->f_count = 0;
        u.u_ofile[r] = NULL;
        iput(ip);
        return;
    }
    u.u_ar0[R1] = u.u_ar0[R0]; /* wf's fd */
    u.u_ar0[R0] = r;           /* rf's fd */
    wf->f_flag = FWRITE|FPIPE;
    wf->f_inode = ip;
    rf->f_flag = FREAD|FPIPE;
    rf->f_inode = ip;
    ip->i_count = 2;
    ip->i_flag = IACC|IUPD;
    ip->i_mode = IALLOC;
}

주석은 여기서 일어나는 일을 명확하게 설명합니다. 그러나 부분적으로 "사용자 u를 구성» 및 레지스터 R0 и R1 시스템 호출 매개 변수와 반환 값이 전달됩니다.

함께 해보자 ialloc() 디스크에 배치 아이노드(inode), 그리고 도움으로 폴록() - 매장 XNUMX개 파일. 모든 것이 순조롭게 진행되면 플래그를 설정하여 이러한 파일을 파이프라인의 두 끝으로 식별하고 동일한 inode(참조 횟수가 2가 됨)를 가리키며 inode를 수정되어 사용 중인 것으로 표시합니다. 에 대한 요청에 주의 입력() 오류 경로에서 새 inode의 참조 횟수를 줄입니다.

pipe() 기한 R0 и R1 읽기 및 쓰기를 위한 파일 설명자 번호를 반환합니다. falloc() 파일 구조에 대한 포인터를 반환하지만 다음을 통해 "반환"하기도 합니다. u.u_ar0[R0] 및 파일 설명자. 즉, 코드는 다음 위치에 저장됩니다. r 읽기를 위한 파일 디스크립터에서 직접 쓰기를 위한 디스크립터를 할당합니다. u.u_ar0[R0] 두 번째 통화 후 falloc().

깃발 FPIPE파이프라인을 만들 때 설정한 는 함수의 동작을 제어합니다. sys2.c의 rdwr(), 특정 I/O 루틴을 호출합니다.

/*
 * common code for read and write calls:
 * check permissions, set base, count, and offset,
 * and switch out to readi, writei, or pipe code.
 */
rdwr(mode)
{
    register *fp, m;

    m = mode;
    fp = getf(u.u_ar0[R0]);
        /* … */

    if(fp->f_flag&FPIPE) {
        if(m==FREAD)
            readp(fp); else
            writep(fp);
    }
        /* … */
}

그런 다음 기능 readp() в pipe.c 파이프라인에서 데이터를 읽습니다. 그러나 다음부터 시작하여 구현을 추적하는 것이 좋습니다. writep(). 다시 말하지만 인수 전달 규칙의 특성으로 인해 코드가 더 복잡해졌지만 일부 세부 정보는 생략될 수 있습니다.

writep(fp)
{
    register *rp, *ip, c;

    rp = fp;
    ip = rp->f_inode;
    c = u.u_count;

loop:
    /* If all done, return. */

    plock(ip);
    if(c == 0) {
        prele(ip);
        u.u_count = 0;
        return;
    }

    /*
     * If there are not both read and write sides of the
     * pipe active, return error and signal too.
     */

    if(ip->i_count < 2) {
        prele(ip);
        u.u_error = EPIPE;
        psignal(u.u_procp, SIGPIPE);
        return;
    }

    /*
     * If the pipe is full, wait for reads to deplete
     * and truncate it.
     */

    if(ip->i_size1 == PIPSIZ) {
        ip->i_mode =| IWRITE;
        prele(ip);
        sleep(ip+1, PPIPE);
        goto loop;
    }

    /* Write what is possible and loop back. */

    u.u_offset[0] = 0;
    u.u_offset[1] = ip->i_size1;
    u.u_count = min(c, PIPSIZ-u.u_offset[1]);
    c =- u.u_count;
    writei(ip);
    prele(ip);
    if(ip->i_mode&IREAD) {
        ip->i_mode =& ~IREAD;
        wakeup(ip+2);
    }
    goto loop;
}

파이프라인 입력에 바이트를 쓰고 싶습니다. u.u_count. 먼저 inode를 잠글 필요가 있습니다(아래 참조). plock/prele).

그런 다음 inode 참조 횟수를 확인합니다. 파이프라인의 양쪽 끝이 열려 있는 한 카운터는 2여야 합니다. rp->f_inode), 따라서 카운터가 2 미만이면 읽기 프로세스가 파이프라인의 끝을 닫았다는 의미입니다. 즉, 닫힌 파이프라인에 쓰기를 시도하고 있는데 이는 실수입니다. 첫 번째 오류 코드 EPIPE 그리고 신호 SIGPIPE 유닉스 XNUMX판에서 등장.

그러나 컨베이어가 열려 있어도 가득 찰 수 있습니다. 이 경우 다른 프로세스가 파이프라인에서 읽고 충분한 공간을 확보할 수 있기를 바라며 잠금을 해제하고 절전 모드로 전환합니다. 깨어나면 처음으로 돌아가서 다시 잠금을 해제하고 새로운 쓰기 주기를 시작합니다.

파이프라인에 충분한 여유 공간이 있으면 다음을 사용하여 데이터를 씁니다. 쓰다(). 모수 i_size1 inode'a(빈 파이프라인이 0일 수 있음)는 이미 포함된 데이터의 끝을 가리킵니다. 쓸 공간이 충분하면 파이프라인을 채울 수 있습니다. i_size1 에 PIPESIZ. 그런 다음 잠금을 해제하고 파이프라인에서 읽기를 기다리는 모든 프로세스를 깨우려고 합니다. 처음으로 돌아가서 필요한 만큼의 바이트를 쓸 수 있었는지 확인합니다. 그렇지 않은 경우 새 기록 주기를 시작합니다.

일반적으로 매개변수 i_mode inode는 권한을 저장하는 데 사용됩니다. r, w и x. 그러나 파이프라인의 경우 비트를 사용하여 일부 프로세스가 쓰기 또는 읽기를 기다리고 있음을 알립니다. IREAD и IWRITE 각기. 프로세스는 플래그를 설정하고 호출합니다. sleep(), 그리고 미래에 다른 프로세스가 호출할 것으로 예상됩니다. wakeup().

진정한 마법은 sleep() и wakeup(). 그들은에서 구현됩니다 slp.c, 유명한 "당신은 이것을 이해하지 못할 것으로 예상됩니다" 댓글의 출처입니다. 운 좋게도 우리는 코드를 이해할 필요가 없습니다. 몇 가지 주석만 살펴보세요.

/*
 * Give up the processor till a wakeup occurs
 * on chan, at which time the process
 * enters the scheduling queue at priority pri.
 * The most important effect of pri is that when
 * pri<0 a signal cannot disturb the sleep;
 * if pri>=0 signals will be processed.
 * Callers of this routine must be prepared for
 * premature return, and check that the reason for
 * sleeping has gone away.
 */
sleep(chan, pri) /* … */

/*
 * Wake up all processes sleeping on chan.
 */
wakeup(chan) /* … */

호출하는 프로세스 sleep() 특정 채널의 경우 나중에 다른 프로세스에 의해 깨어날 수 있습니다. wakeup() 동일한 채널에 대해. writep() и readp() 이러한 페어링 통화를 통해 작업을 조정합니다. 참고 pipe.c 항상 우선순위 PPIPE 부를 때 sleep(), 그래서 모두 sleep() 신호에 의해 중단될 수 있습니다.

이제 기능을 이해하는 데 필요한 모든 것이 있습니다. readp():

readp(fp)
int *fp;
{
    register *rp, *ip;

    rp = fp;
    ip = rp->f_inode;

loop:
    /* Very conservative locking. */

    plock(ip);

    /*
     * If the head (read) has caught up with
     * the tail (write), reset both to 0.
     */

    if(rp->f_offset[1] == ip->i_size1) {
        if(rp->f_offset[1] != 0) {
            rp->f_offset[1] = 0;
            ip->i_size1 = 0;
            if(ip->i_mode&IWRITE) {
                ip->i_mode =& ~IWRITE;
                wakeup(ip+1);
            }
        }

        /*
         * If there are not both reader and
         * writer active, return without
         * satisfying read.
         */

        prele(ip);
        if(ip->i_count < 2)
            return;
        ip->i_mode =| IREAD;
        sleep(ip+2, PPIPE);
        goto loop;
    }

    /* Read and return */

    u.u_offset[0] = 0;
    u.u_offset[1] = rp->f_offset[1];
    readi(ip);
    rp->f_offset[1] = u.u_offset[1];
    prele(ip);
}

이 함수를 아래에서 위로 읽는 것이 더 쉬울 수 있습니다. "읽고 반환" 분기는 일반적으로 파이프라인에 일부 데이터가 있을 때 사용됩니다. 이 경우, 우리는 읽다() 현재 데이터부터 가능한 한 많은 데이터 읽기 f_offset 읽은 다음 해당 오프셋 값을 업데이트합니다.

후속 읽기에서 읽기 오프셋에 도달하면 파이프라인이 비어 있게 됩니다. i_size1 아이노드에서. 위치를 0으로 재설정하고 파이프라인에 쓰기를 원하는 모든 프로세스를 깨우려고 합니다. 컨베이어가 가득 차면 writep() 에 잠들다 ip+1. 이제 파이프라인이 비어 있으므로 절전 모드를 해제하여 쓰기 주기를 재개할 수 있습니다.

읽을 것이 없다면, readp() 플래그를 설정할 수 있습니다 IREAD 그리고 잠들다 ip+2. 우리는 무엇이 그를 깨울지 압니다 writep()파이프라인에 일부 데이터를 쓸 때.

에 대한 댓글 읽기() 및 쓰기i() 매개변수를 전달하는 대신 "u» 파일, 위치, 메모리의 버퍼를 취하고 읽거나 쓸 바이트 수를 계산하는 일반 I/O 함수처럼 처리할 수 있습니다.

/*
 * Read the file corresponding to
 * the inode pointed at by the argument.
 * The actual read arguments are found
 * in the variables:
 *    u_base        core address for destination
 *    u_offset    byte offset in file
 *    u_count        number of bytes to read
 *    u_segflg    read to kernel/user
 */
readi(aip)
struct inode *aip;
/* … */

/*
 * Write the file corresponding to
 * the inode pointed at by the argument.
 * The actual write arguments are found
 * in the variables:
 *    u_base        core address for source
 *    u_offset    byte offset in file
 *    u_count        number of bytes to write
 *    u_segflg    write to kernel/user
 */
writei(aip)
struct inode *aip;
/* … */

"보수적" 차단에 관해서는 readp() и writep() 완료되거나 결과를 얻을 때까지 inode를 잠급니다(예: wakeup). plock() и prele() 간단하게 작업: 다른 호출 세트 사용 sleep и wakeup 방금 해제한 잠금이 필요한 모든 프로세스를 깨울 수 있습니다.

/*
 * Lock a pipe.
 * If its already locked, set the WANT bit and sleep.
 */
plock(ip)
int *ip;
{
    register *rp;

    rp = ip;
    while(rp->i_flag&ILOCK) {
        rp->i_flag =| IWANT;
        sleep(rp, PPIPE);
    }
    rp->i_flag =| ILOCK;
}

/*
 * Unlock a pipe.
 * If WANT bit is on, wakeup.
 * This routine is also used to unlock inodes in general.
 */
prele(ip)
int *ip;
{
    register *rp;

    rp = ip;
    rp->i_flag =& ~ILOCK;
    if(rp->i_flag&IWANT) {
        rp->i_flag =& ~IWANT;
        wakeup(rp);
    }
}

처음에는 왜 그런지 이해할 수 없었습니다. readp() 발생하지 않습니다 prele(ip) 전화하기 전에 wakeup(ip+1). 첫 번째 writep() 루프에서 호출합니다. plock(ip), 다음과 같은 경우 교착 상태가 발생합니다. readp() 아직 블록을 제거하지 않았으므로 코드가 어떻게든 올바르게 작동해야 합니다. 보면 wakeup(), 이는 휴면 프로세스를 실행할 준비가 된 것으로만 표시하므로 미래에 sched() 정말 개시했습니다. 그래서 readp() 원인 wakeup(), 잠금 해제, 설정 IREAD 그리고 전화 sleep(ip+2)-이 모든 전에 writep() 주기를 다시 시작합니다.

이것으로 제XNUMX판의 파이프라인 설명을 마칩니다. 간단한 코드, 광범위한 영향.

XNUMX판 유닉스 (1979년 XNUMX월)은 많은 새로운 응용 프로그램과 커널 기능을 도입한 새로운 주요 릴리스(XNUMX년 후)였습니다. 또한 유형 캐스팅, 공용체 및 구조에 대한 유형 포인터의 사용과 관련하여 상당한 변화를 겪었습니다. 하지만 파이프라인 코드 실질적으로 변하지 않았습니다. 이 버전은 건너뛸 수 있습니다.

Xv6, 간단한 유닉스 계열 커널

핵을 만들려면 XV6 Unix 86판의 영향을 받았지만 x11 프로세서에서 실행되도록 최신 C로 작성되었습니다. 코드는 읽기 쉽고 이해하기 쉽습니다. 또한 TUHS를 사용하는 Unix 소스와 달리 PDP 70/XNUMX이 아닌 다른 곳에서 컴파일, 수정 및 실행할 수 있습니다. 따라서 이 코어는 대학에서 운영 체제에 대한 교재로 널리 사용됩니다. 출처 Github에 있습니다.

코드에는 명확하고 사려 깊은 구현이 포함되어 있습니다. 파이프.c, 디스크의 inode 대신 메모리의 버퍼에 의해 지원됩니다. 여기서는 "구조적 파이프라인"의 정의와 기능만 제공합니다. pipealloc():

#define PIPESIZE 512

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

int
pipealloc(struct file **f0, struct file **f1)
{
  struct pipe *p;

  p = 0;
  *f0 = *f1 = 0;
  if((*f0 = filealloc()) == 0 || (*f1 = filealloc()) == 0)
    goto bad;
  if((p = (struct pipe*)kalloc()) == 0)
    goto bad;
  p->readopen = 1;
  p->writeopen = 1;
  p->nwrite = 0;
  p->nread = 0;
  initlock(&p->lock, "pipe");
  (*f0)->type = FD_PIPE;
  (*f0)->readable = 1;
  (*f0)->writable = 0;
  (*f0)->pipe = p;
  (*f1)->type = FD_PIPE;
  (*f1)->readable = 0;
  (*f1)->writable = 1;
  (*f1)->pipe = p;
  return 0;

 bad:
  if(p)
    kfree((char*)p);
  if(*f0)
    fileclose(*f0);
  if(*f1)
    fileclose(*f1);
  return -1;
}

pipealloc() 함수를 포함하는 나머지 구현의 모든 상태를 설정합니다. piperead(), pipewrite() и pipeclose(). 실제 시스템 호출 sys_pipe 에서 구현된 래퍼입니다. sysfile.c. 그의 모든 코드를 읽는 것이 좋습니다. 난이도는 XNUMX판의 소스코드 수준이지만 훨씬 쉽고 즐겁게 읽을 수 있습니다.

Linux 0.01

Linux 0.01의 소스 코드를 찾을 수 있습니다. 그의 연구에서 파이프라인의 구현을 연구하는 것이 유익할 것입니다. fs/pipe.c. 여기에서는 파이프라인을 나타내는 데 inode가 사용되지만 파이프라인 자체는 최신 C로 작성됩니다. XNUMX판 코드를 통해 해킹을 했다면 여기서 문제가 없을 것입니다. 기능은 이렇게 생겼어요 write_pipe():

int write_pipe(struct m_inode * inode, char * buf, int count)
{
    char * b=buf;

    wake_up(&inode->i_wait);
    if (inode->i_count != 2) { /* no readers */
        current->signal |= (1<<(SIGPIPE-1));
        return -1;
    }
    while (count-->0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<<(SIGPIPE-1));
                return b-buf;
            }
            sleep_on(&inode->i_wait);
        }
        ((char *)inode->i_size)[PIPE_HEAD(*inode)] =
            get_fs_byte(b++);
        INC_PIPE( PIPE_HEAD(*inode) );
        wake_up(&inode->i_wait);
    }
    wake_up(&inode->i_wait);
    return b-buf;
}

구조체 정의를 보지 않고도 inode 참조 카운트를 사용하여 쓰기 작업의 결과가 SIGPIPE. 바이트 단위 작업 외에도 이 기능은 위의 아이디어와 쉽게 비교할 수 있습니다. 짝수 논리 sleep_on/wake_up 그렇게 외계인처럼 보이지 않습니다.

최신 Linux 커널, FreeBSD, NetBSD, OpenBSD

나는 최신 커널을 재빨리 검토했습니다. 그들 중 어느 것도 이미 디스크 기반 구현을 가지고 있지 않습니다(놀랍지 않습니다). Linux에는 자체 구현이 있습니다. 세 가지 최신 BSD 커널에는 John Dyson이 작성한 코드를 기반으로 하는 구현이 포함되어 있지만 수년 동안 서로 너무 달라졌습니다.

읽다 fs/pipe.c (리눅스에서) 또는 sys/kern/sys_pipe.c (*BSD에서) 진정한 헌신이 필요합니다. 벡터 및 비동기 I/O와 같은 기능에 대한 성능 및 지원은 오늘날 코드에서 중요합니다. 그리고 메모리 할당, 잠금 및 커널 구성의 세부 사항은 모두 매우 다양합니다. 이것은 대학에서 운영 체제 입문 과정에 필요한 것이 아닙니다.

어쨌든 몇 가지 오래된 패턴(예: SIGPIPE 그리고 돌아가다 EPIPE 닫힌 파이프라인에 쓸 때) 이 모든 매우 다른 최신 커널에서. 아마도 PDP-11 컴퓨터가 실제로 작동하는 것을 볼 수는 없을 것입니다. 하지만 제가 태어나기 몇 년 전에 작성된 코드에서 여전히 배울 점이 많습니다.

2011년 Divi Kapoor가 작성한 기사 "파이프 및 FIFO의 Linux 커널 구현Linux 파이프라인(지금까지)의 작동 방식에 대한 개요입니다. ㅏ 최근 리눅스 커밋 임시 파일의 기능을 능가하는 상호 작용의 파이프라인 모델을 보여줍니다. 또한 XNUMX판 Unix 커널에서 파이프라인이 "매우 보수적인 잠금"에서 얼마나 멀리 갔는지 보여줍니다.

출처 : habr.com