Project 1 : Threads - Introtuction (급조번역(23.6.22).신용하지 말것- 수정중)

Project1: Threads

 

이 과제에서는 기본적인 동작을 하는 스레드 시스템을 제공합니다. 여러분의 역할은 이 시스템의 기능을 확장하여 동기화 문제에 대한 이해를 높이는 것입니다. 이 과제에서는 주로 threads 디렉토리에서 작업하며, 일부 작업은 devices 디렉토리에서 수행됩니다. 컴파일은 threads 디렉토리에서 진행해야 합니다. 이 프로젝트의 설명을 읽기 전에 적어도 동기화(Synchronization.)에 대한 자료를 대략적으로 훑어보는 것이 좋습니다.

 

 

Background

Understanding Threads

첫 번째 단계는 초기 스레드 시스템의 코드를 읽고 이해하는 것입니다. Pintos는 이미 스레드 생성 및 스레드 완료, 스레드 간 전환을 위한 간단한 스케줄러, 그리고 동기화 기본 요소 (세마포어, 락, 조건 변수 및 최적화 장벽//semaphores, locks, condition variables, and optimization barriers)를 구현하고 있습니다.

 

이 코드 중 일부는 다소 의아하게 보일 수 있습니다. 소개에서 설명한 대로 아직 기본 시스템을 컴파일하고 실행하지 않았다면 지금 컴파일해야 합니다. 소스 코드의 일부를 읽어보고 무슨 일이 일어나고 있는지 확인할 수 있습니다. 원하는 경우 거의 모든 위치에 printf() 호출을 추가한 다음 다시 컴파일하고 실행하여 어떤 일이 어떤 순서로 발생하는지 확인할 수 있습니다. 또한 디버거에서 커널을 실행하여 흥미로운 지점에 중단점을 설정하고, 코드를 한 단계씩 살펴보고 데이터를 검사하는 등의 작업을 수행할 수 있습니다.

 

스레드가 생성되면 스케줄링할 새 컨텍스트가 만들어집니다. 이 컨텍스트에서 실행할 함수를 thread_create()의 인수로 제공합니다. 스레드가 처음 예약되어 실행되면 해당 함수의 시작 부분에서 시작하여 해당 컨텍스트에서 실행됩니다. 함수가 반환되면 스레드가 종료됩니다. 따라서 각 스레드는 핀토스 내부에서 실행되는 미니 프로그램처럼 작동하며, thread_create()에 전달된 함수는 main()처럼 작동합니다.

 

특정 시간에 정확히 하나의 스레드만 실행되고 나머지는 비활성 상태가 됩니다. 스케줄러는 다음에 실행할 스레드를 결정합니다. (주어진 시간에 실행할 준비가 된 스레드가 없으면 idle() 구현된 특수 idle 스레드가 실행됩니다). Synchronization primitives는 한 스레드가 다른 스레드가 무언가를 할 때까지 기다려야 할 때 컨텍스트 전환을 강제할 수 있습니다.

 

context switch의 메커니즘은 threads/thread.c의 thread_launch()에 있습니다. (이해하실 필요는 없습니다.) 현재 실행 중인 스레드의 상태를 저장하고 전환하려는 스레드의 상태를 복원하는 함수입니다.

 

GDB 디버거를 사용하여 컨텍스트 전환을 천천히 추적하여 어떤 일이 발생하는지 확인합니다(GDB 참조). schedule()에 중단점을 설정하여 시작하고 거기서부터 한 단계씩 진행할 수 있습니다. 각 스레드의 주소와 상태, 각 스레드의 호출 스택에 어떤 프로시저가 있는지 추적해야 합니다. 한 스레드가 do_iret()에서 iret을 실행하면 다른 스레드가 실행을 시작하는 것을 알 수 있습니다.

 

경고: 핀토스에서는 각 스레드에 4KB 미만의 작은 고정 크기 실행 스택이 할당됩니다. 커널은 스택 오버플로를 감지하려고 시도하지만 완벽하게 감지할 수는 없습니다. 큰 데이터 구조를 정적이 아닌 지역 변수로 선언하면 이상한 커널 패닉과 같은 기괴한 문제가 발생할 수 있습니다(예: int buf[1000];). 스택 할당의 대안으로는 page allocator와  block allocator 가 있습니다(Memory Allocation 참조).

 

Source Files

다음은 threads 및 include/threads 디렉터리에 있는 파일에 대한 간략한 개요입니다. 이 코드의 대부분을 수정할 필요는 없지만, 이 개요를 제시함으로써 어떤 코드를 살펴봐야 할지에 대한 시작이 되기를 바랍니다.

 

threads codes

- loader.S, loader.h

The kernel loader. 512바이트의 코드와 데이터로 구성되며, PC BIOS가 메모리에 로드하고 디스크에서 커널을 찾아 메모리에 로드한 다음 start.S의 bootstrap()으로 점프합니다. 이 코드를 보거나 수정할 필요는 없습니다. start.S는 메모리 보호에 필요한 기본 설정을 수행하고 64비트 long 모드로 점프합니다.  로더와 달리 이 코드는 실제로 커널의 일부입니다.

 

-kernel.lds.S

커널을 연결하는 데 사용되는 링커 스크립트입니다. 커널의 로드 주소를 설정하고 start.S가 커널 이미지의 시작 부분에 위치하도록 정렬합니다. 다시 말하지만, 이 코드를 보거나 수정할 필요는 없지만 궁금한 경우를 대비하여 여기에 있습니다.

 

-init.c, init.h

커널의 메인 프로그램인 main()을 포함한 커널 초기화. 최소한 main()을 살펴보고 무엇이 초기화되는지 확인해야 합니다. 여기에 자신만의 초기화 코드를 추가할 수도 있습니다.

 

-thread.c, thread.h

기본 스레드 지원. 대부분의 작업은 이 파일에서 이루어집니다. thread.h는 4개의 프로젝트 모두에서 수정할 가능성이 높은 구조체 스레드(struct thread)를 정의합니다. 자세한 내용은 스레드(Threads)를 참조하세요.

 

-palloc.c, palloc.h

페이지 할당기(Page allocator)는 시스템 메모리를 4kB 페이지의 배수로 나눠주는 페이지 할당기입니다. 자세한 내용은 페이지 할당기( Page Allocator)를 참조하세요.

 

-malloc.c, malloc.h

커널용 malloc() 및 free()의 간단한 구현입니다. 자세한 내용은 블록 얼로케이터( Block Allocator )를 참고하세요.

 

-interrupt.c, interrupt.h

기본 인터럽트 처리 및 인터럽트 켜기/끄기 기능.

 

- intr-stubs.S, intr-stubs.h

로우레벨 인터럽트 처리를 위한 어셈블리 코드입니다.

 

-synch.c, synch.h

기본 동기화 기본 요소: semaphores, locks, condition variables, and optimization barriers.. 네 프로젝트 모두에서 동기화를 위해 이 기본 요소를 사용해야 합니다. 자세한 내용은 동기화( Synchronization )를 참조하세요.

 

- mmu.c, mmu.h

x86-64 페이지 테이블 작업용 함수. 실습1이 끝나면 이 파일을 자세히 살펴볼 것입니다.

 

-io.h

I/O 포트 액세스를 위한 함수. This is mostly used by source code in the devices directory that you won't have to touch.

 

-vaddr.h, pte.h

가상 주소( virtual addresses )와 페이지 테이블 항목(page table entries)으로 작업하기 위한 함수 및 매크로. 프로젝트 3에서는 이 기능들이 더 중요해질 것입니다. 지금은 무시해도 됩니다.

 

-flags.h

Macros that define a few bits in the x86-64 flags register. Probably of no interest.

 

devices codes

기본 스레드 커널에는 이러한 파일도 디바이스 디렉터리에 포함되어 있습니다:

 

-timer.c, timer.h

기본적으로 초당 100회 틱(ticks)하는 시스템 타이머입니다. 이 프로젝트에서 이 코드를 수정할 것입니다.

 

-vga.c, vga.h

VGA 디스플레이 드라이버. 화면에 텍스트를 쓰는 일을 담당합니다. 이 코드를 볼 필요가 없습니다. printf() 호출이 VGA 디스플레이 드라이버를 대신 호출하므로 이 코드를 직접 호출할 이유가 거의 없습니다.

 

- serial.c, serial.h

직렬 포트 드라이버. 다시 말하지만, printf()가 이 코드를 대신 호출하므로 사용자가 직접 호출할 필요가 없습니다. 이 코드는 직렬 입력을 입력 레이어로 전달하여 처리합니다(It handles serial input by passing it to the input layer )(아래 참조).

 

-block.c, block.h (현재의 핀토스 프로젝트에서는 이 파일이 이름이 disk.c, disk.h로 보여지는 것이 아닌가 싶다)

블록 디바이스, 즉 고정 크기 블록의 배열로 구성된 랜덤 액세스 디스크와 같은 디바이스를 위한 추상화 계층입니다. Pintos는 기본적으로 두 가지 유형의 블록 장치를 지원합니다: IDE 디스크와 파티션. 유형에 관계없이 블록 장치는 프로젝트 2까지 실제로 사용되지 않습니다.

 

-ide.c, ide.h (핀토스에서 기본적으로 지원하는 블록장치 유형 2가지 중의 하나 ide 디스크)

최대 4개의 IDE 디스크에서 섹터 읽기 및 쓰기를 지원합니다.

 

-partition.c, partition.h ( 핀토스에서 기본적으로 지원하는 블록장치 유형 2가지 중의 하나 파티션(partition)

디스크의 파티션 구조를 이해하여 단일 디스크를 여러 영역(파티션)으로 분할하여 독립적으로 사용할 수 있습니다.

 

-kbd.c, kbd.h

키보드 드라이버. 키 입력을 처리하여 입력 레이어로 전달합니다(아래 참조).

 

-input.c, input.h

입력 레이어. 키보드 또는 직렬 드라이버가 전달한 입력 문자를 대기열(Queue)에 넣습니다.

 

- intq.c, intq.h

인터럽트 큐 - 커널 스레드와 인터럽트 핸들러가 모두 액세스하려는 순환 큐를 관리하기 위한 것입니다. 키보드 및 직렬 드라이버에서 사용됩니다.

 

-rtc.c, rtc.h

실시간 시계 드라이버(Real-time clock driver)를 사용하여 커널이 현재 날짜와 시간을 결정할 수 있도록 합니다. 기본적으로 이 드라이버는 난수 생성기의 초기 시드를 선택하기 위해 thread/init.c에서만 사용됩니다.

 

-speaker.c, speaker.h

PC 스피커에서 톤을 생성할 수 있는 드라이버입니다.

 

-pit.c, pit.h

8254 프로그래밍 가능 인터럽트 타이머(Programmable Interrupt Timer)를 구성하는 코드입니다. 이 코드는 각 장치가 PIT의 출력 채널 중 하나를 사용하기 때문에 devices/timer.c와 devices/speaker.c에서 모두 사용됩니다.

 

lib codes

마지막으로, lib와 lib/kernel에는 유용한 라이브러리 루틴이 포함되어 있습니다. (lib/user는 프로젝트 2부터 사용자 프로그램에서 사용되지만 커널의 일부가 아닙니다.) 다음은 몇 가지 자세한 내용입니다:

 

-ctype.h, inttypes.h, limits.h, stdarg.h, stdbool.h, stddef.h, stdint.h, stdio.c, stdio.h, stdlib.c, stdlib.h, string.c, string.h

표준 C 라이브러리의 하위 집합입니다.

 

-debug.c, debug.h

디버깅을 지원하는 함수 및 매크로. 자세한 내용은 디버깅 도구(See Debugging Tools)를 참조하세요.

 

-random.c, random.h

의사 난수 생성기(Pseudo-random number generator). 실제 난수 값의 순서는 핀토스 실행마다 달라지지 않습니다.

 

-round.h

반올림을 위한 매크로.

 

-syscall-nr.h

System call 번호들. 프로젝트 2까지는 사용되지 않습니다.

 

-kernel/list.c, kernel/list.h

이중 링크 리스트 구현. 핀토스 코드 전체에 사용되며 프로젝트 1에서 몇 군데 직접 사용하게 될 것입니다. 시작하기 전에 이 코드를 훑어보실 것을 권장합니다(특히 헤더 파일에 있는 주석).

 

-kernel/hash.c, kernel/hash.h

해시 테이블 구현. 프로젝트 3에 유용할 것 같습니다.

 

-kernel/console.c, kernel/console.h, kernel/stdio.h

printf() 및 기타 몇 가지 함수를 구현합니다.

 

Synchronization

적절한 동기화는 이러한 문제(these problems)를 해결하는 데 있어 중요한 부분입니다. 인터럽트를 끄면 모든 동기화 문제를 쉽게 해결할 수 있습니다. 인터럽트가 꺼져 있는 동안에는 동시성이 없으므로 race conditions이 발생할 가능성이 없습니다. 따라서 모든 동기화 문제를 이 방법으로 해결하고 싶을 수 있지만, 그렇게 하지 마세요. 대신 semaphores, locks, and condition variables를 사용하여 동기화 문제의 대부분을 해결하세요. 어떤 상황에서 어떤 synchronization primitives를 사용할 수 있는지 잘 모르겠다면 동기화에 대한 둘러보기 섹션(see Synchronization)이나 threads/synch.c의 주석을 읽어보세요.

 

핀토스 프로젝트에서 인터럽트를 비활성화하면 가장 잘 해결되는 유일한 종류의 문제는 커널 스레드와 인터럽트 핸들러 간에 공유되는 데이터를 조정하는 것입니다. 인터럽트 핸들러는 sleep 상태가 될 수 없기 때문에 잠금( locks)을 획득할 수 없습니다. 즉, 커널 스레드와 인터럽트 핸들러 간에 공유되는 데이터는 인터럽트를 해제하여 커널 스레드 내에서 보호해야 합니다.

 

이 프로젝트는 인터럽트 핸들러에서 약간의 스레드 상태만 액세스하면 됩니다. For the alarm clock, 타이머 인터럽트는 sleeping threads를 깨워야 합니다. 고급 스케줄러(advanced scheduler)에서 타이머 인터럽트는 몇 가지 전역 및 스레드별 변수에 액세스해야 합니다. 커널 스레드에서 이러한 변수에 액세스하는 경우 타이머 인터럽트가 간섭하지 못하도록 인터럽트를 비활성화해야 합니다.

 

인터럽트를 끌 때는 가능한 한 최소한의 코드만 사용하도록 주의하세요. 그렇지 않으면 타이머 틱( timer ticks )이나 입력 이벤트( input events)와 같은 중요한 기능이 손실될 수 있습니다. 또한 인터럽트를 끄면 인터럽트 처리 지연 시간이 증가합니다. 그리고 그것은 can make a machine feel sluggish if taken too far.

 

synch.c의 동기화 프리미티브(The synchronization primitives ) 자체는 인터럽트를 비활성화하여 구현됩니다. 여기서 인터럽트를 비활성화한 상태로 실행되는 코드의 양을 늘려야 할 수도 있지만, 그래도 최소한으로 유지해야 합니다.

 

코드 섹션이 중단되지 않도록(not interrupted) 하려는 경우 인터럽트를 비활성화하면 디버깅에 유용할 수 있습니다. 프로젝트를 제출하기 전에 디버깅 코드를 제거해야 합니다. (코드를 주석 처리하면 코드를 읽기 어려울 수 있으므로 그냥 그대로 주석처리 해서 남겨두지 마세요)

 

제출에 busy waiting가 없어야 합니다. thread_yield()를 호출하는 타이트한 루프는 busy waiting의 한 형태입니다.

 

Development Suggestions

과거에는 많은 그룹이 과제를 여러 조각으로 나눈 다음 각 그룹 구성원이 마감 직전까지 각자의 조각을 작업한 다음 그룹이 다시 모여 코드를 결합하여 제출했습니다. 이는 좋지 않은 방법입니다. 이 방법은 권장하지 않습니다. 이렇게 하는 그룹은 종종 두 가지 변경 사항이 서로 충돌하여 막판에 많은 디버깅이 필요한 경우가 많습니다. 이렇게 한 일부 그룹은 테스트를 통과하기는커녕 컴파일이나 부팅조차 되지 않는 코드를 제출하기도 했습니다.

 

대신, git과 같은 소스 코드 제어 시스템을 사용하여 팀의 변경 사항을 조기에 자주 통합하는 것이 좋습니다. 이렇게 하면 모든 사람이 코드가 완성된 시점이 아니라 작성 중인 상태에서 다른 사람의 코드를 볼 수 있으므로 돌발 상황이 발생할 가능성이 적습니다. 또한 이러한 시스템을 사용하면 변경 사항을 검토하고 변경 사항으로 인해 버그가 발생하면 작동 되는 이전 전 코드 버전으로 되돌릴 수 있습니다.

 

이 프로젝트와 후속 프로젝트를 작업하는 동안 이해하지 못하는 버그가 발생할 수 있습니다. 그럴 때는 유용한 디버깅 팁이 담긴 디버깅 도구에 대한 부록을 다시 읽어보시면 도움이 될 것입니다(see Debugging Tools). 모든 커널 패닉(kernel panic) 또는 어설션 실패(assertion failure)를 최대한 활용하는 데 도움이 되는 backtraces (see Backtraces) 섹션도 반드시 읽어보세요.