🧠 카피 온 라이트(Copy-on-Write): 진짜 복사는 나중에!

1) fork()의 오해와 진실

📌 기본 동작

리눅스에서 fork() 함수는 부모 프로세스를 그대로 복사해 자식 프로세스를 만듭니다. 그런데 정말로 "모든 메모리"를 복사할까요?

❌ 아니요! fork()는 실제 메모리를 바로 복사하지 않습니다.
✅ 대신, 페이지 테이블만 복사하고, 물리 메모리는 공유합니다.

리눅스에서 fork() 함수는 부모 프로세스를 복제하여 자식 프로세스를 생성합니다. 하지만 메모리까지 전부 복사하면 너무 느리고 메모리 낭비겠죠? 그래서 리눅스는 카피 온 라이트(Copy-on-Write, CoW) 기법을 활용합니다.

🧩 페이지 테이블만 복사된 상태 예시

프로세스	가상 주소	물리 주소	쓰기 권한
부모	0~100	500~600	❌
부모	100~200	600~700	❌
자식	0~100	500~600	❌
자식	100~200	600~700	❌

부모와 자식 모두 같은 물리 주소를 참조하지만, 쓰기 권한은 제거된 상태입니다.

이 방식 덕분에:

• fork() 실행이 매우 빠릅니다 ✅
• 메모리도 많이 절약됩니다 ✅

2) 쓰려고 하면 생기는 일: 진짜 복사, 등장!

✨ Copy-on-Write(CoW)란?

fork() 직후 부모와 자식은 물리 메모리를 공유하지만, 쓰기 시도 순간 복사가 발생합니다. 이게 바로 Copy-on-Write입니다.

페이지 테이블 엔트리 내부에는 페이지에 쓰기 권한을 관리하는 필드가 있는데, 이때 부모와 자식 양쪽을 대상으로 모든 페이지에 쓰기 권한을 무효화합니다.

부모와 자식: "우린 같은 책을 읽고 있어요(읽기 전용)"
자식: "여기 좀 고쳐야겠어!" ➜ 페이지 폴트 발생!
커널: "자, 새 책 줄게. 거기다 써!"

🔐 페이지 테이블에서 쓰기 권한을 무효화하는 이유

1) 페이지 테이블(Page Table)과 권한 필드

운영체제는 페이지 테이블(Page Table)을 통해 가상 주소를 물리 주소로 변환할 뿐 아니라, 각 페이지에 대한 접근 권한(읽기/쓰기/실행 등)도 함께 관리합니다.

페이지 테이블의 각 항목을 Page Table Entry(PTE)라고 부르는데, 여기에 다음과 같은 정보가 포함되어 있어요:

필드명	설명
Physical Address	매핑된 물리 주소
R (Read)	읽기 권한
W (Write)	쓰기 권한
X (Execute)	실행 권한
...	기타 캐시, 접근 여부 등

2) 왜 fork() 후에 쓰기 권한을 없앨까?

fork()를 호출하면 자식은 부모의 복사본이 되지만, 진짜 메모리를 복사하지는 않아요.

대신 부모와 자식 모두 같은 물리 메모리를 공유하게 됩니다.

하지만 이 상태에서 누군가 그 메모리를 수정해버리면?
→ 공유 중이던 메모리가 망가질 수 있어요.

그래서!

✅ 부모와 자식의 페이지 테이블 모두에서 "쓰기 권한"을 제거해버립니다.
즉, 읽기 전용(read-only)으로 만들어버리는 거죠.

🧠 내부 동작 요약

이후에 메모리를 읽을 때 부모와 자식 사이에 공유된 물리 페이지에 접근 가능합니다.

한편, 부모와 자식 중 어느 쪽이 데이터를 갱신하려고 하면 페이지 공유를 해제하고, 프로세스마다 전용 페이지를 만듭니다. 자식 프로세스가 페이지 데이터를 갱신하면 아래와 같은 일이 일어납니다.

1. 자식이 어떤 페이지에 쓰기 시도
2. 쓰기 권한 없음 → CPU에서 페이지 폴트(Page Fault) 발생
3. CPU가 커널 모드로 바뀌고 커널의 페이지 폴트 핸들러가 동작
4. 페이지 폴트 핸들러는 접속한 페이지를 별도의 물리 메모리에 복사
5. 자식의 페이지 테이블을 해당 메모리로 업데이트
6. 이제부터 부모와 자식은 각자의 메모리 사용

✅ 즉, 처음 쓰는 순간에만 복사하고, 그전까지는 공유로 처리합니다.

fork() 직후 부모-자식 모두 쓰기 권한을 제거하는 이유는, 쓰기 시도 시점까지 메모리를 공유하게 하기 위해서예요!

시점	상태	설명
fork() 직후	부모와 자식의 페이지에 모두 쓰기 권한 ❌	메모리는 공유 중
자식이 쓰기 시도	페이지 폴트 발생 → 복사 발생	이제부터 자식은 독립된 메모리
부모는 그대로	아직 쓰기 안 하면 여전히 공유 중	효율적 메모리 사용 가능

3) 실험 코드: CoW 실제 확인해보기 (cow.py)

📜 실험 개요

1. 100MiB 메모리 확보 후 fork()

2. fork 직후 자식 메모리 사용량 확인

• 시스템 전체의 물리 메모리 사용량, 프로세스의 물리 메모리 사용량, 메이저 폴트 횟수, 마이너 폴트 횟수를 출력

3. fork() 함수를 호출

4. 자식이 메모리 접근(쓰기) → 다시 확인

• 자식 프로세스 종료를 대기.
• 자식 프로세스를 대상으로 2와 동일한 정보를 출력
• 1에서 확보한 영역의 모든 페이지에 접근
• 자식 프로세스를 대상으로 2와 동일한 정보를 출력

📦 핵심 코드

import mmap, os, subprocess, sys

ALLOC_SIZE = 100*1024*1024
PAGE_SIZE = 4096

def access(data):
    for i in range(0, ALLOC_SIZE, PAGE_SIZE):
        data[i] = 0

def show_meminfo(msg, who):
    print(msg)
    subprocess.run("free")
    subprocess.run(["ps", "-orss,maj_flt,min_flt", str(os.getpid())])
    print()

data = mmap.mmap(-1, ALLOC_SIZE, flags=mmap.MAP_PRIVATE)
access(data)

show_meminfo("*** 자식 생성 전 ***", "부모")
pid = os.fork()

if pid == 0:
    show_meminfo("*** 자식 생성 직후 ***", "자식")
    access(data)
    show_meminfo("*** 자식 메모리 접근 후 ***", "자식")
    sys.exit(0)

os.wait()

4) 실험 결과 해석

시점	시스템 전체 메모리 변화	RSS 변화	마이너 폴트 수
자식 생성 직후	약 1MiB 증가	거의 동일	적음
자식 메모리 접근 후	약 100MiB 증가	유사	매우 많음

• 카피 온 라이트를 이용하면 프로세스가 fork() 함수를 호출한 순간에는 메모리를 전부 복사하지 않아도 되므로 fork() 함수 처리가 빨라지고 메모리 사용량도 줄어듭니다.
• 프로세스를 생성해도 모든 메모리에 쓰기 작업이 발생하는 건 극히 드문 일이므로 시스템 전체 메모리
  사용량도 줄어듭니다.

📌 요점 정리:

• 자식 생성만으로는 메모리 거의 사용 안 함
• 쓰기 이후에만 실제 RAM 복사 발생
• RSS는 공유 여부 무관하게 물리 메모리 할당된 총합을 보여줌

RSS 참고

참고 : RSS(Resident Set Size) 는 프로세스가 실제 물리 메모리(RAM)에서 차지하고 있는 크기를 말합니다.

그렇기에 RSS는 ‘실제 점유 중인 메모리'이라기보다는 RSS는 실제 메모리 점유량을 보여주는 것처럼 보이지만, 공유된 메모리도 포함되어 있어서, 여러 프로세스가 같은 메모리(예: 공유 라이브러리)를 쓰고 있어도 각자 따로따로 계산해요.

📌 그래서 여러 프로세스의 RSS 값을 다 더하면 실제 물리 메모리 총합보다 훨씬 클 수도 있어요!

즉, RSS 값은 물리 메모리의 "공유 상태"는 고려하지 않기 때문입니다.

예시로 이해하기

$ ps -o pid,rss,cmd -p 1234
  PID   RSS CMD
1234  20480 /usr/bin/python3 myscript.py

→ 이건 1234번 프로세스가 약 20MB의 RAM을 점유 중이라는 뜻이지만,
그 중 일부는 다른 프로세스와 공유하고 있을 수도 있다는 점을 잊지 마세요!

다른 메모리 지표들과 비교

출처 : https://blog.naver.com/ya3344/221599131853?viewType=pc

지표	설명
VSZ (Virtual Set Size)	프로세스가 사용할 수 있도록 예약된 가상 메모리 전체 크기
RSS (Resident Set Size)	실제 메모리에 올라간 크기 (공유 포함)
PSS (Proportional Set Size)	공유 메모리를 각 프로세스에 비례해서 나눠 계산한 값 (정확함)

📌 ps 명령어는 기본적으로 RSS만 보여주지만, 더 정확한 값을 원하면 smem이나 procfs에서 PSS를 확인하는 것이 좋아요!

5) 시각 자료: Copy-on-Write 시나리오

[부모 & 자식 프로세스]
   👨 ➡️ fork() ➡️ 👶

[초기 상태]
  가상 주소: 동일
  물리 주소: 동일
  쓰기 권한: ❌

[자식이 쓰기를 시도]
  ⛔ 페이지 폴트 발생
  🔁 커널: 메모리 복사
  ✅ 자식 전용 메모리로 업데이트

✅ 한 줄 요약

Copy-on-Write는 쓰기할 때만 진짜 복사를 하는 똑똑한 전략이다.

메모리 참고 사진

출처 : https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.alibabacloud.com%2Fhelp%2Fen%2Farms%2Fapplication-monitoring%2Fdeveloper-reference%2Fmemory-metrics&psig=AOvVaw2-VxYDaw7nN9hnu9SW34rT&ust=1744677892712000&source=images&cd=vfe&opi=89978449&ved=0CBcQjhxqFwoTCNimluKl1owDFQAAAAAdAAAAABAT

🚀 execve()와 Demand Paging: 메모리는 ‘진짜’ 쓸 때 주는 거야

1) Demand Paging이 뭐였더라?

💡 Demand Paging은 필요할 때만 메모리를 물리 메모리에 로딩하는 기법이에요.
처음부터 다 올리는 게 아니라, 접근할 때 페이지 폴트(Page Fault)가 발생하면 그때 메모리를 할당해요.

출처 : https://www.sitesbay.com/os/os-what-is-demand-paging-in-operating-system

• 페이지에 접근을 시도합니다.
• 페이지가 유효하다면(메모리에 있다면) 정상적으로 명령어 처리를 계속합니다.
• 페이지가 유효하지 않으면 페이지 오류 트랩이 발생합니다.
• 메모리 참조가 보조 메모리의 특정 위치에 대한 유효한 참조인지 확인합니다. 유효하지 않으면 프로세스가 종료됩니다(불법적인 메모리 접근). 유효하지 않으면 필요한 페이지를 페이지 인해야 합니다.
• 원하는 페이지를 주 메모리로 읽어들이도록 디스크 작업을 예약합니다.
• 운영 체제 트랩으로 인해 중단된 명령어를 다시 시작합니다.

예를 들어, 큰 책을 빌렸는데 처음 몇 장만 읽을 거면 굳이 전체를 복사할 필요가 없겠죠? 필요한 쪽만 복사해도 충분하니까요.

2) execve()에서 Demand Paging은 어떻게 작동할까?

execve() 함수는 새로운 프로그램을 로딩할 때 사용돼요. 이 함수가 호출되면:

1. 기존 프로세스의 메모리는 전부 초기화됩니다.
2. 실행할 프로그램의 메모리 구조만 설정되고, 물리 메모리는 할당되지 않아요!
3. 이후 코드가 실행되며 페이지에 접근할 때, 그제서야 메모리가 할당됩니다.

즉, "코드를 읽는 순간까지도 물리 메모리는 할당되지 않은 상태"라는 뜻입니다.

출처 : http://www.hexainclude.com/demand-paging/

프로세스가 메모리에 존재하지 않는 페이지에 접근하려고 할 때, 유효하지 않은 것으로 표시된 페이지에 접근하면 페이지 폴트 또는 페이지 누락 인터럽트가 발생합니다. OS는 인터럽트 처리기로 제어권을 넘깁니다. 페이지 폴트 인터럽트임을 확인하면 가상 메모리 처리기를 호출합니다.

인터럽트 핸들러는 페이지 폴트(pi)를 발생시킨 페이지 번호를 가상 핸들러에 전달합니다. 가상 메모리는 사용 가능한 프레임 목록을 확인하고 해당 페이지를 스왑 공간에서 메모리로 로드합니다. 커널은 해당 항목으로 페이지 테이블을 수정하여 해당 페이지가 유효해지도록 합니다.

참고로 인터럽트 핸들러(영어: interrupt handler) 또는 인터럽트 서비스 루틴(영어: interrupt Service Routine, ISR)은 인터럽트 접수에 의해 발생되는 인터럽트에 대응하여 특정 기능을 처리하는 기계어 코드 루틴입니다.

출처 : https://mns010.tistory.com/12

3) 단계별 흐름 정리

🖼 그림 05-03: execve() 호출 직후

• 가상 주소만 존재하고, 물리 주소 연결은 없음
• 아직 페이지에 접근하지 않았으므로 페이지 폴트도 없음

🖼 그림 05-04: 엔트리 포인트 접근 → 페이지 폴트 발생

• 실행 지점 진입
• 해당 페이지가 물리 메모리에 없으므로 페이지 폴트 발생!

🖼 그림 05-05: 페이지 폴트 처리 후 메모리 할당

• 커널이 페이지 폴트를 감지하고
• 필요한 페이지를 RAM에 복사
• 가상 주소 ↔ 물리 주소 연결 완료

🖼 그림 05-06: 다른 페이지 접근 → 반복 처리

• 그 이후 다른 페이지 접근할 때도 동일한 방식으로 페이지 폴트가 발생
• 해당 페이지마다 물리 메모리 할당이 이루어짐

4) Demand Paging의 장점은?

항목	내용
🔄 지연 로딩	실제로 쓰기 전까지 메모리를 로딩하지 않음
💾 메모리 절약	필요 없는 페이지는 끝까지 로딩되지 않을 수 있음
🚀 실행 속도 개선	프로그램 실행 시점에서 필요한 부분만 로딩해서 빠르게 시작 가능
📉 캐시 효율	자주 접근하는 페이지만 유지하면 캐시 히트율 향상 가능

5) execve() + Demand Paging 흐름 요약

[1] execve() 호출
      ↓
[2] 프로그램 메모리 맵 구성 (물리 메모리는 아직 없음)
      ↓
[3] 코드 실행 시작 → 첫 페이지 접근 시 페이지 폴트 발생
      ↓
[4] 해당 페이지만 물리 메모리에 로딩 (나머지는 아직 없음)
      ↓
[5] 이후 필요한 페이지마다 on-demand로 메모리 로딩

💭 비유

execve()는 가상 주소만 준비해놓고, 실제 메모리는 ‘접근할 때’ 하나씩 받아오는 효율적인 시스템!

"책을 한꺼번에 다 읽지 않고, 필요한 페이지부터 넘기기 시작하는 것과 같아요!"

🧠 공유 메모리를 통한 프로세스 통신: 자식과 부모가 같은 종이를 본다면?

1) 프로세스끼리 대화하려면?

컴퓨터에서 여러 프로그램이 함께 일하려면 서로 데이터를 주고받는 통신 수단이 필요합니다. 이를 IPC (Inter-Process Communication, 프로세스 간 통신)이라고 해요.

출처: https://heeonii.tistory.com/13 [우당탕탕 히온이네:티스토리]

위 그림처럼 프로세스는 완전히 독립된 실행객체로써 다른 프로세스의 영향을 받지 않습니다. 독립되어 있는 만큼 별도의 설비가 없이 서로간의 통신이 어려워, 커널 영역에서 IPC라는 내부 프로세스 간 통신을 제공하여 프로세스는 커널이 제공하는 IPC설비를 이용해서 프로세스 간 통신을 가능하게 합니다. 

리눅스는 다양한 IPC 방식을 지원하는데, 그중에서도 “공유 메모리(shared memory)”는 가장 빠른 방식 중 하나입니다.

2) 공유하지 않을 때 어떤 일이 벌어질까?

먼저, 일반적인 fork() 이후 데이터 공유 없이 자식이 값을 바꿨을 때를 보겠습니다.

💻 코드 예시: non-shared-memory.py

#!/usr/bin/python3
import os
import sys

data = 1000
print("자식 프로세스 생성 전 데이터 값: {}".format(data))
pid = os.fork()

if pid == 0:
    data = 2  # 자식이 값을 바꿈
    sys.exit(0)

os.wait()
print("자식 프로세스 종료 후 데이터 값: {}".format(data))

🧪 결과

자식 프로세스 생성 전 데이터 값: 1000  
자식 프로세스 종료 후 데이터 값: 1000

❓ 왜 값이 안 바뀌었을까?

fork() 함수를 호출한 이후의 부모와 자식 프로세스는 데이터를 공유하지 않기 때문에 어떤 한쪽의 데이터를 갱신하더라도 다른 쪽 프로세스에 있는 데이터에는 영향을 주지 않습니다.

• fork()는 부모의 메모리를 복사하지만, Copy-on-Write(CoW) 때문에 쓰기 시도 시 복제됩니다.
• 자식이 데이터를 바꾸면 자신만의 사본을 갖게 되어, 부모 입장에서는 변경 사항을 모르게 되는 거죠.

3) 그럼 진짜 공유하려면? → 공유 메모리(mmap + MAP_SHARED)

이번엔 자식과 부모가 같은 메모리 공간을 바라보도록 설정해볼게요.

출처: https://heeonii.tistory.com/13 [우당탕탕 히온이네:티스토리]

📦 공유 메모리란 무엇인가요?

1) 기본 개념

공유 메모리(shared memory)는 여러 프로세스가 동일한 메모리 공간에 접근할 수 있도록 해주는 설비입니다.

기본적으로 프로세스는 자기만의 독립된 메모리 공간을 가지고 있어요. 커널은 이를 보호해서 다른 프로세스가 접근하거나 간섭하지 못하게 합니다. 하지만 때때로, 서로 협력해야 하는 상황에서는 데이터를 함께 사용해야 할 필요가 생기죠.

2) 왜 공유 메모리가 필요할까?

❓ 프로세스끼리 데이터를 주고받고 싶다면?

• 파이프(PIPE), 메시지 큐 등의 전통적인 IPC 방식은 데이터를 주고받는 데 중개자 역할을 필요로 합니다.
• 반면, 공유 메모리는 중개 없이 곧바로 메모리에 접근하게 만들어줍니다.
• 이는 스레드(Thread)처럼 공통 메모리 공간을 공유하는 방식과 유사해요.

3) 어떻게 동작하나요?

🧠 작동 흐름

1. 프로세스 A가 커널에 공유 메모리를 요청합니다.
2. 커널은 해당 프로세스에 공유 가능한 메모리 공간을 할당합니다.
3. 프로세스 B도 같은 공유 메모리 공간을 매핑받으면,
4. 이제 A와 B는 동일한 메모리 공간을 읽고 쓸 수 있게 됩니다.

4) 특징과 장점

항목	설명
🧭 직접 접근	커널의 중재 없이 메모리에 곧바로 접근 가능
⚡ 매우 빠름	모든 IPC 중에서 가장 빠른 방식
📈 메모리 증가 없음	단순히 포인터로 접근하므로 물리적 메모리 사용량은 증가하지 않음
🔄 양방향 통신 가능	읽기 + 쓰기 모두 가능한 구조

5) 언제 사용하면 좋을까?

• 프로세스 간에 실시간으로 데이터를 주고받아야 할 때
• 양방향 통신이 필요할 때
• 속도가 매우 중요한 시스템(예: 게임 엔진, DB 공유 캐시 등)

공유 메모리는 여러 프로세스가 하나의 메모리 공간을 함께 사용함으로써, 빠르고 효율적인 데이터 교환을 가능하게 해주는 IPC 방식입니다.

💻 코드 예시: shared-memory.py

#!/usr/bin/python3
import os, sys, mmap
from sys import byteorder

PAGE_SIZE = 4096
data = 1000
print("자식 프로세스 생성 전 데이터 값: {}".format(data))

# 공유 메모리 생성
shared_memory = mmap.mmap(-1, PAGE_SIZE, flags=mmap.MAP_SHARED)

# 초기값 저장
shared_memory[0:8] = data.to_bytes(8, byteorder)

pid = os.fork()

if pid == 0:
    # 자식이 메모리 읽고 2배로 만들기
    data = int.from_bytes(shared_memory[0:8], byteorder)
    data *= 2
    shared_memory[0:8] = data.to_bytes(8, byteorder)
    sys.exit(0)

os.wait()
# 부모가 값 확인
data = int.from_bytes(shared_memory[0:8], byteorder)
print("자식 프로세스 종료 후 데이터 값: {}".format(data))

동작 방식

1. 정수 데이터 1000을 만들어서 데이터 값을 출력합니다.
2. 공유 메모리 영역을 작성해서 1 데이터 값을 영역 첫 부분에 저장합니다.
3. 자식 프로세스를 만듭니다.
4. 부모 프로세스는 자식 프로세스 종료를 기다립니다. 자식 프로세스는 2에서 만든 데이터 값을 읽고 2배로 만들어서 공유 메모리 영역에 다시 기록합니다. 그러고 나서 자식 프로세스는 종료합니다.
5. 부모 프로세스는 데이터 값을 출력합니다.

4) 실험 결과

자식 프로세스 생성 전 데이터 값: 1000  
자식 프로세스 종료 후 데이터 값: 2000

✅ 이번엔 변경된 값이 반영됨!

• 이유는 간단해요. 부모와 자식이 같은 메모리 공간을 사용하고 있기 때문이죠.
• mmap()을 MAP_SHARED 플래그와 함께 쓰면, 메모리 영역이 프로세스 간 공유됩니다.

5) 공유 메모리의 구조 이해

6) 실생활 비유로 이해하기

마치 부모와 자식이 같은 칠판을 보고 글씨를 쓰는 것과 같아요.
자식이 1000을 2000으로 바꿔 쓰면, 부모가 그걸 고스란히 볼 수 있겠죠?

공유 메모리는 부모와 자식이 같은 메모리 공간을 보게 해서, 데이터가 정말로 '공유'되도록 만들어줍니다!

🔔 시그널로 통신한다고요? – 프로세스끼리 '신호' 주고받기

1) 시그널(Signal)이란?

출처 : https://hasumang.tistory.com/11

시그널(Signal)은 리눅스에서 프로세스 간에 비동기적으로 신호를 주고받는 방법입니다.
프로세스에게 어떤 사건이 발생했음을 알려주는 간단한 메시지 역할을 해요.

예시로 자주 쓰는 시그널들:

시그널 이름	의미
SIGINT	인터럽트 (Ctrl+C)
SIGTERM	종료 요청
SIGKILL	강제 종료 (kill -9)

이 시그널들은 용도가 정해진 시스템 시그널이에요. 사용자 프로그램이 임의로 해석하지 않고, 시스템이 자동 처리하는 경우가 많습니다.

2) 자유롭게 사용할 수 있는 시그널: SIGUSR1, SIGUSR2

사용자가 직접 정의해서 쓸 수 있는 시그널도 있어요!

• SIGUSR1, SIGUSR2는 사용자 정의 시그널입니다.
• 개발자가 원하는 의미를 부여해서, 두 프로세스가 서로 통신하거나 진행 상태를 전달하는 데 사용할 수 있습니다.

예를 들면, 프로세스 A가 B에게 “지금 데이터 처리 중이야”, 또는 “다음 단계로 넘어가”라는 신호를 보내는 식이죠.

3) 하지만... 시그널에는 한계가 있어요

특징	설명
⚠ 단순함	시그널은 오직 "왔다"는 사실만 알림
⛔ 데이터 전달 불가	시그널만으로는 수치나 문자열 등 실제 데이터는 전송 불가
➕ 별도 수단 필요	따라서 실제 데이터를 주고받으려면 공유 메모리, 파이프 등 다른 IPC 방식과 함께 사용해야 함

4) 💡 실전 예제: dd 명령어에 시그널 보내기

리눅스의 dd 명령어는 SIGUSR1 시그널을 받으면 복사 진행 상태를 출력하는 숨은 기능이 있어요.

▶️ 사용 예시

$ dd if=/dev/zero of=test bs=1 count=1G &
[1] 2992194        # 백그라운드 PID

$ DDPID=$!         # 최근 백그라운드 PID 저장

$ kill -SIGUSR1 $DDPID
# 출력:
8067496+8 records in  
8067496+0 records out  
8067496 bytes (8.1 MB, 7.7 MiB) copied, 15.3716 s, 525 kB/s

📌 해석:

• kill -SIGUSR1은 dd 프로세스에 "상태 출력해줘!"라고 신호를 보낸 거예요.
• 그 결과, 현재까지 몇 바이트를 복사했는지 실시간으로 보여줍니다.
• SIGUSR1을 여러 번 보내면 중간중간 진행 상황을 계속 알 수 있죠!

시그널은 프로세스에게 '무언가 일어났어!'라고 알려주는 단순한 알림 도구이며,
복잡한 통신보다는 간단한 트리거용으로 사용하는 것이 좋습니다.

좋습니다! 위 내용을 바탕으로 익명 파이프(Anonymous Pipe)와 명명된 파이프(Named Pipe)의 개념과 차이를 중심으로, 발표나 블로그용으로 보기 좋고 이해하기 쉬운 방식으로 정리해드릴게요.

---

🔄 파이프(PIPE)로 하는 프로세스 간 통신

1) 파이프란?

파이프(pipe)는 한 프로세스의 출력 데이터를 다른 프로세스의 입력으로 전달하는 통신 수단입니다.

리눅스에서는 쉘에서 다음과 같은 명령어를 자주 사용하죠:

$ free | awk '(NR==2){print $2}'

• free: 메모리 정보를 출력
• |: 파이프 → free의 출력을 awk의 입력으로 전달
• awk: 전달받은 입력에서 특정 필드만 추출

파이프를 사용하는 가장 친숙한 예를 들자면
bash 같은 셸에서 문자로 프로그램끼리 처리 결과를 연계하는 것

이처럼 파이프는 간단하고 직관적인 단방향 통신 수단으로 시작했지만, 프로세스 간 통신(IPC)에서도 중요한 역할을 합니다.

쌍방통신을 위해서는 Write용 PIPE하나 Read PIPE하나를 따로 만들어야 합니다. read()와write()가 기본적으로 block 모드로 작동하기 때문에 프로세스가 read가 대기중이라면 read가 끝나기 전에는 write를 할 수가 없게 됩니다.

2) 익명 파이프 (Anonymous Pipe)

✅ 개요

항목	설명
특징	이름이 없는 임시적인 파이프
통신 방식	단방향
사용 조건	공통 부모를 가진 프로세스 간 (ex. 부모-자식)
생성 함수	pipe() 시스템 콜
데이터 흐름	FIFO (먼저 쓴 게 먼저 읽힘)
제한	같은 부모를 가진 프로세스 간에만 사용 가능

💡 예시

r, w = os.pipe()
os.write(w, b'hello')
print(os.read(r, 5))  # b'hello'

⚠ 단점

• 쌍방향 통신이 어려움: write용, read용 파이프 2개 필요
• block 모드: read()가 대기 중이면 write()도 막힙니다

3) 명명된 파이프 (Named Pipe, FIFO)

1) Named Pipe의 개념

Named Pipe(명명된 파이프)는 이름이 부여된 파일을 통해 전혀 관련 없는 프로세스끼리도 통신할 수 있도록 해주는 리눅스 IPC(프로세스 간 통신) 방식입니다.

• 단방향 통신을 지원합니다.
• FIFO (First-In-First-Out) 구조를 따릅니다.
• 파일 시스템에 등록된 이름을 통해 프로세스들이 이 파이프를 공유할 수 있습니다.

항목	설명
특징	이름이 있는 파이프 파일을 통해 통신
통신 방식	단방향
사용 조건	완전히 독립적인 프로세스 간에도 사용 가능
생성 방법	mkfifo() 시스템 콜 또는 mkfifo 명령어
데이터 흐름	FIFO 구조
파일 시스템 상 존재	✔ (ex. /tmp/mypipe)

2) 익명 파이프와의 차이점

항목	익명 파이프 (Anonymous)	명명된 파이프 (Named)
이름	없음	있음 (/tmp/mypipe 등)
사용 범위	부모-자식 관계의 프로세스만 사용 가능	완전히 별개의 프로세스도 사용 가능
생성 방식	pipe() 함수	mkfifo 명령어 또는 mkfifo() 함수
존재 위치	메모리 내부	파일 시스템 상의 파일로 생성됨

3) Named Pipe의 생성과 사용 흐름

▶ 생성

$ mkfifo /tmp/mypipe

• 이 명령을 실행하면 /tmp/mypipe 라는 이름을 가진 파이프 파일이 생성됩니다.

▶ 사용

터미널 1 (쓰기 측)

$ echo "안녕 프로세스 B!" > /tmp/mypipe

터미널 2 (읽기 측)

$ cat < /tmp/mypipe
안녕 프로세스 B!

⚠ 주의할 점

• read()와 write()는 기본적으로 blocking 모드입니다.
  즉, 한쪽이 준비되지 않으면 다른 쪽도 멈춘 상태가 됩니다.
• 쌍방향 통신이 필요하다면 2개의 파이프를 따로 만들어야 합니다.
  • 예: pipeAtoB, pipeBtoA

✅ Named Pipe의 핵심 요약

• 이름 있는 파일을 이용한 단방향 통신 수단
• 전혀 다른 프로세스 간 통신 가능
• 빠르고 단순하지만 데이터를 전달하려면 읽기/쓰기 블로킹을 고려해야 함

출처: https://heeonii.tistory.com/13 [우당탕탕 히온이네:티스토리]

💡 예시

# 파이프 생성
$ mkfifo mypipe

# 터미널 1
$ echo "Hello" > mypipe

# 터미널 2
$ cat < mypipe
Hello

⚠ 단점

• 익명 파이프와 마찬가지로 쌍방향 통신을 위해 2개 필요
• 블로킹(blocking) 특성: 읽기/쓰기가 서로 기다림

4) 두 파이프 비교 정리

항목	익명 파이프 (Anonymous Pipe)	명명된 파이프 (Named Pipe)
이름	없음	있음 (파일 시스템에 생성)
생성 방식	pipe()	mkfifo() 또는 명령어 mkfifo
사용 범위	부모-자식 등 관련된 프로세스	전혀 다른 프로세스 간에도 사용 가능
방향성	단방향 (쌍방향은 2개 필요)	단방향 (쌍방향은 2개 필요)
연결	파일 기술자(File Descriptor) 기반	파일 경로(Path) 기반

익명 파이프는 관련된 프로세스끼리, 명명된 파이프는 이름만 알면 누구나 통신 가능!

출처 : https://heeonii.tistory.com/13

그렇다면 쌍방향 통신이 가능한 구조는? 소켓

보충 정리 : 🔁 파이프에서 쌍방향 통신 가능한가요?

1) 기본 파이프(익명/명명된 파이프)

항목	기본 특징
통신 방향	단방향 (한쪽은 쓰기, 한쪽은 읽기만 가능)
쌍방향 구현	읽기용 파이프 + 쓰기용 파이프 2개 만들어야 함
차단 특성	기본적으로 read() / write()는 블로킹 I/O

✅ 그래서 기본 pipe() 또는 mkfifo()만 사용하면 진정한 쌍방향 통신은 불가능합니다.

2) 진짜 쌍방향 통신이 가능한 구조는?

✅ 유닉스 도메인 소켓(Unix Domain Socket)

파이프보다 한 단계 진화한 구조로, 하나의 연결만으로 양방향 통신이 가능합니다.

항목	설명
양방향 통신	O (한 개의 소켓으로 read/write 모두 가능)
프로세스 관계	관계 없는 프로세스끼리도 사용 가능
구현 방식	socketpair() 또는 AF_UNIX 소켓
성능	빠르고, 메모리 복사도 효율적

📌 리눅스의 socketpair(AF_UNIX, SOCK_STREAM) 함수는 실제로 양방향 파이프를 구현한 것으로 보시면 됩니다.

3) socketpair()가 구현된 예 (C 예시)

int fd[2];
socketpair(AF_UNIX, SOCK_STREAM, 0, fd);

// fd[0]과 fd[1] 모두 읽기/쓰기 가능!

위와 같은 구조는 파이프처럼 동작하지만, 양방향 통신이 기본입니다.

✅ 결론

기본 PIPE는 단방향이지만,
쌍방향이 필요하다면 다음 2가지 방법 중 하나를 써야 해요:

1. PIPE를 2개 만들어서 각각 읽기/쓰기에 사용
2. Unix Domain Socket을 사용해서 양방향으로 처리

🧵 리눅스에서의 소켓(Socket)은?

1) 소켓이란?

소켓은 프로세스 간 통신(IPC) 또는 네트워크 통신을 가능하게 해주는 양방향 통신 인터페이스입니다.

소켓은 크게 2가지로 나뉩니다:

종류	용도	설명
네트워크 소켓	원격 통신	TCP/UDP를 이용한 IP 기반 통신
유닉스 도메인 소켓	로컬 통신	같은 머신 내의 프로세스 간 통신

2) 리눅스에서 지원하는 대표 소켓들

소켓 종류	프로토콜	설명
AF_INET	TCP/UDP	IPv4 네트워크 통신
AF_INET6	TCP/UDP	IPv6 네트워크 통신
AF_UNIX	local	유닉스 도메인 소켓 (같은 머신 내 프로세스 간 통신)
AF_NETLINK	커널 ↔ 사용자 공간	주로 리눅스 커널과 사용자 공간 간 메시지 전달
AF_PACKET	저수준 패킷 접근	네트워크 인터페이스 수준의 패킷 통신

3) 리눅스에서 소켓 사용하는 방식은?

C, Python, Go, Java 등 대부분의 언어에서 리눅스 소켓 API를 사용할 수 있어요!

// C에서 소켓 생성 예시
int sockfd = socket(AF_INET, SOCK_STREAM, 0);

# Python에서 TCP 클라이언트 예시
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("127.0.0.1", 8080))

리눅스는 이와 같은 소켓을 시스템 콜로 관리하며, /proc 시스템에서도 소켓 정보를 확인할 수 있습니다.

4) 유닉스 도메인 소켓도 리눅스에서 완벽 지원

• AF_UNIX, AF_LOCAL로 정의
• /tmp/mysocket 같은 실제 파일 경로를 사용해서 프로세스 간 통신 가능
• socketpair()로 양방향 파이프 대체 가능

int fds[2];
socketpair(AF_UNIX, SOCK_STREAM, 0, fds);
// fds[0], fds[1] → 서로 읽고 쓰기 가능

리눅스는 네트워크든 로컬이든, 다양한 종류의 소켓 통신을 완벽하게 지원합니다.
파이프보다 강력하고 유연한 IPC 수단으로 자주 사용돼요!

그 외 IPC

📬 리눅스 IPC: 메시지 큐, 공유 메모리, 메모리 맵 정리

출처 : https://heeonii.tistory.com/13

Message Queue (메시지 큐)

✅ 개념

• 파이프가 단순히 데이터를 흘려보내는 통로라면, 메시지 큐는 '라벨이 붙은 컨베이어 벨트'처럼 동작합니다.
• 각 메시지는 msgtype이라는 ID 값을 가지고 있어, 여러 프로세스가 동시에 메시지를 주고받을 수 있어요.
• 구조체 단위로 데이터를 전송하며, FIFO 방식으로 처리됩니다.

입출력 방식으로는 익명 PIPE와 동일하지만, 커널에서 관리하며 메모리를 사용한 PIPE 입니다. 구조체 기반으로 통신을 합니다.

✅ 리눅스에서 어떻게 쓰이나요?

• 리눅스에서는 msgget(), msgsnd(), msgrcv(), msgctl() 등의 시스템 콜을 통해 메시지 큐를 생성하고 관리합니다.
• 커널이 메시지 큐를 관리하며, 한계(크기 제한)가 있기 때문에 메시지 큐가 꽉 차면 msgsnd()가 블로킹됩니다.

✅ 특징 요약

항목	내용
통신 방향	단방향 (일반적으로)
데이터 단위	구조체 기반 메시지
관리 주체	커널
특징	msgtype 기반으로 다양한 데이터 분기 처리 가능

Memory Map (메모리 맵)

✅ 개념

• Memory Map은 공유 메모리와 유사하지만, 파일을 메모리에 매핑해서 공유한다는 점에서 다릅니다.
• 예를 들어, 두 프로세스가 같은 파일을 mmap()해서 메모리에 올리면, 서로 같은 파일 내용을 공유하게 됩니다.
• 커널이 내부적으로 페이지 단위로 메모리-파일 매핑을 효율적으로 관리합니다.

✅ 리눅스에서 어떻게 쓰이나요?

=

• mmap() 시스템 콜을 이용해서 파일을 특정 가상 주소 영역에 맵핑합니다.
• 대부분의 운영체제는 실행 파일도 메모리 맵 방식으로 로딩합니다. (execve() 내부적으로 사용됨)
• 공유 모드(MAP_SHARED)와 개인 모드(MAP_PRIVATE)를 선택할 수 있어요.

✅ 특징 요약

항목	내용
통신 방향	양방향 (MAP_SHARED 사용 시)
데이터 단위	파일 기반
관리 주체	커널 (파일 시스템 + 메모리 매핑)
특징	대용량 데이터 공유에 적합, 파일 기반

🔐 세마포어 (Semaphore)

세마포어는 리눅스에서 프로세스 간 동기화를 위해 사용되는 IPC 메커니즘입니다. 특히, 공유 자원에 대한 접근을 제어하여 동시성 문제를 방지하는 데 유용합니다.

✅ 리눅스에서의 세마포어 사용

리눅스에서는 두 가지 유형의 세마포어를 지원합니다:

1. System V 세마포어: semget(), semop(), semctl() 등의 시스템 콜을 사용합니다.
2. POSIX 세마포어:
   • Unnamed 세마포어: sem_init(), sem_wait(), sem_post(), sem_destroy() 등을 사용하며, 주로 스레드 간 동기화에 활용됩니다.
   • Named 세마포어: sem_open(), sem_close(), sem_unlink() 등을 사용하며, 프로세스 간 동기화에 적합합니다.

🔧 예제

#include <semaphore.h>
#include <pthread.h>

sem_t sem;

void* thread_func(void* arg) {
    sem_wait(&sem);
    // 임계 영역
    sem_post(&sem);
    return NULL;
}

int main() {
    sem_init(&sem, 0, 1);
    pthread_t t1, t2;
    pthread_create(&t1, NULL, thread_func, NULL);
    pthread_create(&t2, NULL, thread_func, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    sem_destroy(&sem);
    return 0;
}

이 예제는 두 개의 스레드가 세마포어를 사용하여 임계 영역에 대한 접근을 제어하는 모습을 보여줍니다.

📡 원격 프로시저 호출 (RPC)

RPC(Remote Procedure Call)는 다른 주소 공간에 있는 프로시저나 함수를 호출할 수 있게 해주는 통신 메커니즘입니다. 이를 통해 분산 시스템에서 프로세스 간 통신을 간편하게 구현할 수 있습니다.

✅ 리눅스에서의 RPC 사용

리눅스에서는 다양한 RPC 구현체를 사용할 수 있습니다:

• ONC RPC: 리눅스에서 기본적으로 제공하는 RPC 구현체로, rpcgen 도구를 사용하여 인터페이스를 정의하고 코드를 생성합니다.
• gRPC: Google에서 개발한 고성능, 범용 오픈 소스 RPC 프레임워크로, HTTP/2와 Protocol Buffers를 기반으로 합니다.

🔧 예제 (ONC RPC)

1. 인터페이스 정의 (example.x):

program EXAMPLE_PROG {
    version EXAMPLE_VERS {
        int add(int, int) = 1;
    } = 1;
} = 0x20000001;

2. 코드 생성:

rpcgen example.x

3. 서버 및 클라이언트 구현: 생성된 스텁 코드를 기반으로 서버와 클라이언트 코드를 작성합니다.

이러한 방식으로 리눅스에서 RPC를 구현하여 프로세스 간 통신을 수행할 수 있습니다.

📋 IPC 방식 요약표

IPC 종류	PIPE	Named PIPE	Message Queue	Shared Memory	Memory Map	Socket	Semaphore	RPC
용도	부모 자식 간 단방향 통신	다른 프로세스와 단방향 통신	다른 프로세스와 단방향 통신	다른 프로세스와 양방향 통신	다른 프로세스와 양방향 통신	다른 시스템 간 양방향 통신	공유 자원 접근 제어 및 동기화	다른 시스템 함수 원격 호출
공유 매개체	파일	파일	메모리	메모리	파일 + 메모리	소켓	메모리 (카운터 기반)	네트워크 (TCP/IP, gRPC 등)
통신단위	stream	stream	구조체	구조체	페이지	stream	정수 (카운터, 플래그)	함수 호출 (요청/응답 메시지)
통신방향	단방향	단방향	단방향	양방향	양방향	양방향	제어 중심 (데이터 전달 X)	양방향

• Semaphore는 데이터를 직접 전달하지 않지만, 임계 영역 보호와 동기화에 핵심적인 IPC 방식입니다.
• RPC는 다른 컴퓨터나 프로세스에서 실행 중인 함수를 마치 내 함수처럼 호출할 수 있게 해주는 IPC입니다. 분산 시스템에서 매우 중요하게 사용됩니다.

일단, 세마포어는 IPC 방식이 아닐 수도 있다는 논의사항이 나왔다.

🔒 리눅스에서의 배타적 제어(Mutual Exclusion)

✅ 배경 설명

운영체제에서 동시에 하나 이상의 프로세스가 자원에 접근하려 할 때, 충돌이 발생할 수 있습니다.

예시로, 우분투에서 사용하는 APT 패키지 시스템이 있어요:

• 두 개 이상의 apt 명령이 동시에 실행되면 데이터베이스 손상이 발생할 수 있음
• 이를 막기 위해 시스템은 한 번에 하나의 apt만 실행되도록 강제합니다

이러한 메커니즘을 우리는 배타적 제어(Exclusive Control) 또는 상호 배제(Mutual Exclusion) 라고 부릅니다.

🧪 실험: 파일 증가 스크립트 inc.sh

#!/bin/bash
TMP=$(cat count)
echo $((TMP + 1)) > count

• 이 스크립트는 count 파일을 읽고 값에 1을 더합니다.
• 1000번 순차 실행 → 정상적으로 1000이 됨
• 그러나 병렬(&)로 실행하면 예상치 못한 결과 (예: 18) 가 출력됨

왜 이런 문제가 발생할까요?

A 프로세스가 count 파일에서 읽음 → 값 0
B 프로세스도 count 파일에서 읽음 → 값 0
A가 count 파일에 1 씀
B도 count 파일에 1 씀
→ 최종 결과는 '1' (둘 다 1씩 더했지만 실제 증가는 1)

이처럼 파일 입출력이 아토믹하지 않아서 중간에 끼어드는 경우가 생깁니다.

💥 아토믹하지 않아서가 뭘까?

아토믹(Atomic)이란 말은 원자처럼 쪼갤 수 없는 단위의 동작이라는 뜻이에요.

즉, 중간에 끊기거나 다른 작업이 끼어들 수 없는 연산을 말해요.

📦 비유해볼게요

• 어떤 사람이 문을 열고 들어가서 닫는다는 작업을 한다고 해봐요.
• 그런데 문 열기 → 들어가기 → 문 닫기가 하나의 완전한 일(아토믹)이어야 안전하죠?

그런데 중간에 다른 사람이 끼어들 수 있다면 문제가 생기겠죠:

A가 문을 열었는데 B가 먼저 들어와버림
→ A, B 둘 다 들어가게 됨 → 충돌 발생

💻 그럼 파일 입출력에서 왜 문제가 되나요?

자, inc.sh 예시를 다시 보면:

TMP=$(cat count)       # 1️⃣ 파일 읽기
echo $((TMP + 1)) > count   # 2️⃣ 1 더해서 다시 쓰기

이 작업은 겉보기엔 하나처럼 보이지만, 내부적으로는 두 개의 독립된 작업이에요.

즉, 읽고(cat) → 계산 → 쓰고(echo) 이 3단계가 하나의 아토믹 작업이 아닌 거예요.

그래서 중간에 다른 프로세스가 끼어들 수 있습니다!

🧪 실제 문제 상황

# 두 개의 프로세스가 동시에 실행될 때

A: cat count  # count = 0 읽음
B: cat count  # count = 0 읽음
A: echo 1 > count
B: echo 1 > count

💥 실제로는 두 번 증가했어야 하는데,
→ 결과는 1만 반영됨 (B가 A를 덮어씀)

파일 입출력은 기본적으로 "아토믹하지 않다"
→ 즉, 중간에 다른 프로세스가 끼어들 수 있어서 충돌이 생길 수 있음
→ 그래서 flock, semaphore, mutex 같은 락 도구로 보호해야 함

🚫 잘못된 배타적 제어 예시: inc-wrong-lock.sh

#!/bin/bash
while; do
  if [ ! -e lock ]; then  # 1) 락 없네?
    break                 # 2) 들어가자!
  fi
done

touch lock               # 3) 락 걸기 (늦었어요!)
TMP=$(cat count)
echo $((TMP + 1)) > count
rm -f lock

• 이 방식은 lock 파일 존재 여부를 검사한 뒤 생성하는 방식
• 하지만 touch lock 전까지 다른 프로세스가 끼어들 수 있음
• 결국 동시 접근 방지에 실패

순서	A 프로세스	B 프로세스
1	lock 파일 존재 여부 확인 → 없음	lock 파일 존재 여부 확인 → 없음
2	"좋아, 들어간다!"	"좋아, 나도 들어간다!"
3	touch lock	touch lock
4	count 읽고 1 더함	count 읽고 1 더함
5	같은 값을 count에 씀	같은 값을 count에 씀

결국 둘 중 하나의 결과만 반영되고, 나머지는 덮어쓰기 당함!

이런 문제를 피하려면 count 값을 읽어서 1을 더하고 그 값을 count 파일에 다시 쓰는 처리가 한 번에 하나의 inc.sh 프로그램에서만 실행되도록 해야 합니다.

이걸 실제로 구현하는 방법이 상호 배제입니다

✅ 올바른 배타적 제어: flock 사용 예시

✔ flock을 이용한 inc-lock.sh

#!/bin/bash
flock lock ./inc.sh

• flock 명령은 파일에 락을 설정해서 중복 실행을 막아줌
• 여러 프로세스가 동시에 접근해도 자동으로 순서대로 실행됨
• 결국 실행 결과는 정확히 1000

🧠 개념 정리

용어	의미
크리티컬 섹션(임계구역)	동시에 실행되면 안 되는 코드 구간
아토믹 처리	외부에서 봤을 때 하나의 처리처럼 보이는 연산
File Lock	특정 파일에 락을 걸어 다른 프로세스의 접근을 제어

• 크리티컬 섹션 : inc.sh 프로그램이라면 count 값을 읽어서 1을 더하고 count 파일에 다시 쓰는 처리에 해당합니다.

📌 리눅스에서 배타적 제어를 구현하는 방법들

방식	리눅스 지원 여부	특징
flock()	✅ 지원	가장 간단한 파일 기반 락
fcntl()	✅ 지원	좀 더 정밀한 락 제어 가능
semaphore	✅ 지원	메모리 동기화 기반 락
pthread_mutex	✅ (스레드 전용)	스레드 간 락을 위한 구조체

리눅스에서는 flock 같은 도구를 사용하여 중요한 작업을 "한 번에 하나"만 처리되도록 배타적 제어를 구현할 수 있습니다.

🧠 파일 락(File Lock)은 어떻게 구현될까?

1) 고급 언어 수준의 파일 락 vs CPU 수준 락

일반적으로 우리는 flock(), fcntl(), pthread_mutex_lock() 등을 사용해 파일이나 메모리를 락으로 보호합니다. 하지만 이러한 함수들 내부적으로는 CPU가 제공하는 락 명령어를 사용합니다.

즉, 진짜 락은 기계어 수준에서 구현되며, 우리가 사용하는 고급 API는 그 위에 만들어진 추상화 계층일 뿐이에요.

2) 락을 기계어로 구현하면?

책에서는 가상의 어셈블리 언어를 통해 간단한 락 메커니즘을 설명합니다. 이 예시를 통해 아토믹(atomic)하지 않으면 어떤 문제가 생기는지 보여줍니다.

🧾 가상 어셈블리 코드 (코드 05-07)

start:
  load r0, mem       ; mem에서 값을 r0에 로드
  test r0            ; r0이 0인지 확인
  jmpz enter         ; 0이면 (lock 안 걸림) → enter
  jmp start          ; 그렇지 않으면 → 다시 시작

enter:
  store mem, 1       ; lock 걸기
  <크리티컬 섹션 실행>
  store mem, 0       ; lock 해제

이 방식은 mem이 0인지 읽고(lock 상태 확인), 1로 바꾸고(lock 설정), 크리티컬 섹션 실행 후 0으로 돌리는 구조입니다.

3) ⚠ 문제점: 이 방식은 안전하지 않다!

위 코드는 겉보기에 잘 동작할 것 같지만, 실제로는 문제가 많습니다. 왜일까요?

• load → test → store 과정이 분리되어 있어서 중간에 끼어들 수 있음
• 예를 들어 두 개의 스레드가 거의 동시에 load를 실행하면, 둘 다 mem = 0으로 판단하고 락을 획득하려고 할 수 있음
• 결과적으로 두 스레드가 동시에 크리티컬 섹션에 진입하는 문제 발생 → 락 실패!

4) 해결책: 아토믹 명령어 사용

대부분의 현대 CPU는 이런 문제를 방지하기 위해 "아토믹 연산(Atomic Instruction)"을 제공합니다.

대표적인 예:

명령어 이름	설명
Test and Set	값을 확인한 후 변경
Compare and Swap	조건에 맞으면 값을 변경
Exchange (XCHG)	두 값을 교환 (락 구현에 자주 사용)

이러한 명령어들은 중간에 끼어들 수 없도록 CPU 수준에서 완전한 원자성 보장을 제공합니다.

5) 참고 알고리즘: 피터슨의 알고리즘 (Peterson’s Algorithm)

• 공유 메모리 기반에서 두 개의 프로세스 간 락을 구현하는 고전적 알고리즘
• 현대 CPU 아토믹 명령이 등장하기 전까지 이론적으로 중요한 기초였어요
• 지금도 동기화의 개념적 이해에 매우 유용한 자료입니다

Peterson's algorithm은 busy waiting을 기반으로 하며, 교육적 목적에서 주로 사용됩니다.

진짜 락은 CPU 내부에서 아토믹 명령어로 구현되며, 고급 언어의 락 함수들은 이 아토믹 연산 위에 만들어진 추상화 도구입니다.

🧠 멀티프로세스와 멀티스레드, 그리고 커널 스레드 vs 사용자 스레드

1️⃣ 병렬 프로그래밍의 두 가지 방식

현대 CPU는 멀티코어로 구성되어 있어, 여러 작업을 동시에 수행할 수 있는 환경이 마련되어 있습니다.

이를 활용하기 위해 프로그램을 병렬로 실행하는 방법은 다음 두 가지입니다:

방식	설명
멀티프로세스 (Multi-process)	여러 개의 독립적인 프로그램을 동시에 실행
멀티스레드 (Multi-thread)	하나의 프로그램을 여러 흐름(스레드)으로 나누어 실행

2️⃣ 멀티프로세스: 프로세스를 나눠서 실행

• fork() 또는 execve()를 통해 독립된 자식 프로세스 생성
• 각 프로세스는 자신만의 가상 주소 공간을 갖고 있으며, 자원 공유가 어려움
• 프로세스 간 통신(IPC)이 필요함 (예: Pipe, Message Queue 등)

예: 웹 서버가 요청마다 프로세스를 새로 생성

3️⃣ 멀티스레드: 같은 프로세스 내에서 흐름을 나눔

• pthread_create() 등으로 프로세스 내에 여러 흐름 생성
• 모든 스레드는 공유된 메모리 공간(가상 주소)에서 실행됨
• 스레드 간 통신이 간편하지만, 동기화 문제가 존재 (mutex 등 필요)

예: 하나의 서버 프로세스가 여러 클라이언트를 처리하기 위해 스레드 사용

4️⃣ 사용자 스레드 vs 커널 스레드

구분	사용자 스레드 (User-level)	커널 스레드 (Kernel-level)
관리 주체	사용자 공간의 스레드 라이브러리	커널
생성/전환 비용	낮음	높음
커널에서의 인식	모든 사용자 스레드 = 하나의 커널 스레드	각각 커널 스레드로 인식
병렬성	제한적 (한 번에 하나만 실행)	실제 병렬 실행 가능
예시	goroutine (Go), green thread	리눅스 스레드, Java thread (OS 연동됨)

5️⃣ 스케줄링에서의 차이점

커널 스레드

• 커널은 각 스레드를 개별적으로 인식
• A의 스레드 0, 1도 각각 독립적으로 CPU를 할당받을 수 있음

사용자 스레드

• 커널 입장에서는 프로세스 A의 스레드 0, 1을 구분하지 못함
• CPU는 프로세스 A 전체에 할당되고, 스레드 간 스케줄링은 라이브러리 내부에서 처리

6️⃣ 기타 참고 정보

• 커널이 직접 생성하는 커널 스레드도 존재함
  • ps aux에서 [kthreadd], [rcu_gp] 등 []로 감싸진 이름은 커널 스레드
  • PID=2인 kthreadd가 루트이며, 다양한 커널 스레드를 자식으로 생성함

멀티프로세스는 독립적인 실행 단위, 멀티스레드는 하나의 공간 안에서의 병렬 흐름이며, 사용자 스레드는 가볍지만 병렬성이 낮고, 커널 스레드는 무겁지만 진짜 병렬 실행이 가능합니다.