cedis 님의 블로그

크래프톤 정글 · Week 9 WIL · Pintos Project 1 ThreadsPintos, 완성된 교향곡에서 베이스를 찾는 과정9주차가 끝났고, 내 손에는 Pintos 글 3편과 로드맵, 테스트 기반 구현 가이드가 남았다.숫자보다 중요한 건 그 과정에서 내가 운영체제 코드를 읽는 방식이 바뀌었다는 점이다.이번 주를 한 줄로 정리하면이번 Pintos 프로젝트는 완성된 교향곡 속에서 흐름을 이해하기 위해 베이스를 찾아가는 과정이었다.처음에는 모든 파일과 함수가 동시에 울리는 것 같았다. 어느 함수가 주선율인지, 어떤 interrupt가 박자를 잡는지, 어떤 테스트가 낮게 깔린 베이스처럼 전체 흐름을 붙들고 있는지 보이지 않았다. 이번 주는 그 소음을 한 줄씩 분리해서 듣는 시간이었다.이번 주 목표 3..

운영체제 · Pintos · Project 1 Threads · 3편Pintos MLFQS: nice, recent_cpu, load_avg로 Project 1 마무리하기1편에서는 alarm-priority를 통해 ready list의 priority 정렬을 봤고, 2편에서는 기본 Priority Scheduler와 donation을 정리했습니다. 이번 3편은 Project 1 Threads의 마지막 축인 MLFQS(Multi-Level Feedback Queue Scheduler)입니다. 핵심은 단순합니다. 이제 priority를 사람이 직접 정하는 것이 아니라, scheduler가 수식으로 계속 다시 계산합니다.이번 글에서 다루는 것MLFQS가 기본 Priority Scheduler와 어떻게 다른지n..

운영체제 · Pintos · Project 1 Threads · 2편Pintos 기본 Priority Scheduler: waiters 정렬과 priority donation 구현하기1편에서는 alarm-priority를 통해 ready list를 priority 순서로 유지해야 한다는 점을 봤습니다. 이번 글은 그 다음 단계입니다. 깃북이 요구하는 기본 Priority Scheduling을 기준으로 semaphore, condition variable, lock donation까지 연결해서 정리합니다.이번 글에서 다루는 것깃북의 Priority Scheduling 요구사항을 한글로 다시 정리깃북 문장을 테스트와 코드 수정 지점으로 바꾸는 첫삽FIFO 대기열을 priority-aware 대기열로 바꾸는 ..

운영체제 · Pintos · Project 1 Threads · 1편Pintos alarm-priority: ready_list 우선순위 정렬로 출력 순서 맞추기이번 글은 Pintos Project 1 전체가 아니라 Alarm 테스트 중 alarm-priority에서 드러난 우선순위 문제를 다룹니다. timer_sleep()과 busy waiting은 배경으로만 보고, 실제 코드 분석은 thread.c의 ready list 정렬 수정에 맞춥니다.이번 글에서 다루는 것Alarm Clock 테스트가 thread 상태 전이를 어떻게 확인하는지alarm-priority가 왜 ready list 정렬 문제로 이어지는지실제로 반영한 thread_priority_more, thread_unblock(), thread..

Dave O'HallaronTiny 코드에 대입한 흐름Accept -> doit(connfd) -> Rio_readlineb -> method == "GET" -> read_requesthdrs -> parse_uri("/home.html") -> stat("./home.html") -> serve_static -> mmap -> Rio_writen(connfd, file)13-2. 동적 콘텐츠 요청 확인동적 콘텐츠는 파일을 그대로 보내는 것이 아니라, 실행 파일을 돌린 결과가 응답이 되는 경로다. 아래 요청에서 ? 뒤의 n1=15000&n2=213은 parse_uri에서 cgiargs로 분리되고, serve_dynamic에서 QUERY_STRING 환경변수로 넘어간다.curl --htt..

1편에서는 데이터가 컴퓨터 밖에서 frame, packet, segment로 포장되어 이동하는 그림을 잡았다. 이번 글에서는 같은 일을 컴퓨터 안쪽에서 본다. 응용 프로그램이 write(sockfd, buf, n) 한 줄을 호출하면, 운영체제와 하드웨어는 실제로 무엇을 하는가?이번 글에서 다루는 것소켓은 물리적인 구멍이 아니라 커널의 소프트웨어 객체라는 점fd, FDT, VFS, socket object가 어떻게 이어지는지socket, bind, listen, accept, connect 호출 순서CSAPP helper 함수 open_clientfd, open_listenfd, RIO 함수가 무엇을 자동화하는지TCP와 UDP의 차이, 3-way handshake, byte stream과 datagram송..

CSAPP 11장 공부 기록 1편CSAPP 11장을 처음 읽을 때 가장 먼저 막힌 지점은 소켓 코드가 아니었다. Ethernet, bridge, router, LAN, WAN, frame, packet 같은 말이 현실 장비와 바로 연결되지 않았다. 이 글은 그 혼동을 풀기 위해, 데이터가 내 컴퓨터 밖에서 어떤 이름과 포장으로 이동하는지 정리한 1편이다.이번 글에서 다루는 것클라이언트-서버 트랜잭션이 정확히 무엇인지현실 장비 기준으로 Ethernet, hub, switch, bridge, router, LAN, WAN을 구분하는 법데이터가 TCP/IP 4계층을 내려가며 어떤 헤더를 얻는지frame, packet, segment가 왜 같은 듯 다른 말인지IP는 최종 주소이고, MAC은 이번 구간 주소라는 ..

[주간 회고] 네트워크를 읽는 방식이 바뀐 일주일 🧭 이번 주를 한 줄로 정리하면 책으로만 훑고 지나가던 네트워크를, Tiny와 Proxy를 직접 붙잡고 디버깅하며 '내가 실제로 제어하고 확인할 수 있는 흐름'으로 바꿔 낸 시간이었다. 이번 주 학습 축 1. 네트워크 개념의 시스템적 재정의 클라이언트-서버 모델을 기반으로, 추상적인 도메인 이름이 getaddrinfo 계열의 시스템 콜을 통해 어떻게 구체적인 소켓 주소 구조체로 번역되는지 시스템 수준에서 이해했다. 2. 소켓과 커널의 내부 흐름 listen과 ..

👥 3인 팀 프로젝트 🎤 발표자 시점 회고 🛠️ C · HTTP API · Thread Pool · B+ Tree GitHub 저장소: github.com/Jungle-12-303/week8_team6 한 줄 요약: 지난주에 만든 SQL 처리기와 B+ Tree 인덱스를 내부 DB 엔진으로 재사용하고, 그 앞에 C 기반 HTTP API 서버와 Thread Pool을 붙여 외부 클라이언트가 SQL을 실행할 수 있게 만들었습니다.왜 이 프로젝트가 특별했는가정글에서 했던 여러 팀 프로젝트 중에서도 이번 프로젝트는 유독 오래 기억에 남습니다. 이유는 단순한 애착 때문만은 아닙니다. 3인 팀으로 역할을 나눠 구현한 결과물을 하나의 시스템으로 묶어내야 했고, 그 최종 구조와 선택의 이유를 제가 직접 발표해야 했..

크래프톤 정글 · 주간 회고크래프톤 정글 — Week 7 WIL 이번 주는 구현을 더 많이 했다기보다, 지금 보고 있는 구조를 설명 가능한 상태로 끝까지 밀어붙인 주에 가까웠다. malloc은 빈 공간을 찾는 함수 묶음이 아니라 탐색 경로를 설계하는 문제처럼 보이기 시작했고, CS:APP 9장은 그 allocator가 결국 어떤 가상 메모리 바닥 위에 놓이는지 연결해 줬다. Mini SQL 쪽에서는 B+Tree와 디스크 persist, 성능표 해석을 다시 보면서 인덱스가 자료구조이면서 동시에 저장장치 문제라는 것도 더 또렷해졌다. 이번 주를 한 줄로 정리하면지난주 WIL이 상태 정의와 실행 구조를 보는 감각을 붙잡는 시간이었다면, 이번 주는 그 감각을 메모리 관리와 저장 구조 쪽으로 더 깊게 밀어 넣은 ..