스레드 (컴퓨팅)

컴퓨터 과학에서 실행 스레드(thread)는 일반적으로 운영체제의 일부인 스케줄러가 독립적으로 관리할 수 있는 가장 작은 프로그래밍된 명령어 시퀀스이다.^[1] 많은 경우, 스레드는 프로세스의 구성 요소이다.

특정 프로세스의 여러 스레드는 병렬적으로(멀티스레딩 기능을 통해) 실행될 수 있으며, 메모리와 같은 리소스를 공유하지만, 서로 다른 프로세스는 이러한 리소스를 공유하지 않는다. 특히 프로세스의 스레드들은 실행 가능한 코드와 동적 할당된 변수 값, 스레드 로컬이 아닌 전역 변수들을 특정 시점에 공유한다.

스레드와 프로세스의 구현 방식은 운영체제마다 다르다.^[2]

역사

스레드는 1967년 IBM의 일괄 처리 운영체제인 OS/360에서 "태스크(tasks)"라는 이름으로 초기 형태가 등장했다. 이 시스템은 사용자에게 세 가지 OS/360 제어 시스템 구성을 제공했으며, 그중 하나가 가변 태스크 수의 멀티프로그래밍(MVT)이었다. 살처(1966)는 "스레드"라는 용어를 처음 사용한 사람으로 빅터 A. 비소츠키를 지목했다.^[3]

Mach의 스레드 구현은 1986년 여름에 기술되었다.^[4] 1987년에 출시된 OS/2 1.0은 스레드를 지원했다.^[5] 디지털 리서치의 MP/M 운영체제는 1979년 인텔 8080 프로세서에서, 1981년 8086 프로세서에서 멀티프로그래밍, 멀티태스킹, 선점형 멀티태스킹을 제공했다. 스레드를 지원한 최초의 윈도우 버전은 1993년에 출시된 윈도우 NT였다.

1995년 IEEE는 다양한 유닉스 계열 운영체제에서 이식 가능한 멀티스레드 프로그래밍을 위한 표준 인터페이스인 POSIX 스레드(pthreads) API를 정의했다.^[6] 그 이후로 pthreads는 기존 윈도우 API 위에서 표준을 구현하는 pthreads-w32와 같은 타사 패키지를 통해 윈도우에서도 구현되었다.^[7]

2000년대 초반 CPU가 멀티코어를 활용하기 시작하면서 소프트웨어 애플리케이션에서 스레드 사용이 더 보편화되었다. 성능 향상을 위해 멀티코어를 활용하려는 애플리케이션들은 병행성을 사용하여 멀티코어를 활용해야 했다.^[8]

스케줄링

선점형 vs 협동형 스케줄링

운영체제는 스레드를 선점형 또는 협동형으로 스케줄링한다. 다중 사용자 운영체제는 문맥 교환을 통해 실행 시간에 대한 세밀한 제어가 가능하므로 일반적으로 선점형 멀티스레딩을 선호한다. 그러나 선점형 스케줄링은 프로그래머가 예상하지 못한 순간에 스레드를 문맥 교환할 수 있으며, 이는 우선순위 역전, 우선순위 역전 또는 기타 부작용을 일으킬 수 있다. 반면 협동형 멀티스레딩은 스레드가 실행 제어권을 포기하는 것에 의존하며, 이를 통해 스레드가 완료될 때까지 실행되도록 보장한다. 이는 협동형으로 멀티태스킹된 스레드가 리소스를 기다리면서 차단되거나 집중적인 계산 중에 실행 제어권을 양보하지 않아 다른 스레드를 굶주리게 할 경우 문제를 일으킬 수 있다.

단일 vs 멀티프로세서 시스템

2000년대 초반까지 대부분의 데스크톱 컴퓨터는 단일 코어 CPU만 탑재하고 있었으며, 하드웨어 스레드에 대한 지원도 없었다. 하지만 스레드 간 전환이 일반적으로 전체 프로세스 문맥 교환보다 빨랐기 때문에 그러한 컴퓨터에서도 스레드가 사용되었다. 2002년 인텔은 펜티엄 4 프로세서에 하이퍼스레딩이라는 이름으로 동시 멀티스레딩 지원을 추가했으며, 2005년에는 듀얼 코어 펜티엄 D 프로세서를 도입했고 AMD는 듀얼 코어 애슬론 64 X2 프로세서를 도입했다.

단일 프로세서를 갖춘 시스템은 일반적으로 시간 분할을 통해 멀티스레딩을 구현한다. 중앙 처리 장치(CPU)는 서로 다른 소프트웨어 스레드 사이를 전환한다. 이 문맥 교환은 보통 사용자가 스레드나 태스크가 병렬로 실행되는 것처럼 인식할 만큼 빈번하게 발생한다(인기 있는 서버/데스크톱 운영체제의 경우, 다른 스레드가 대기 중일 때 스레드의 최대 시간 분할은 종종 100~200ms로 제한됨). 멀티프로세서 또는 멀티코어 시스템에서는 여러 스레드가 병렬로 실행될 수 있으며, 모든 프로세서나 코어가 별도의 스레드를 동시에 실행한다. 하드웨어 스레드가 있는 프로세서나 코어에서는 별도의 소프트웨어 스레드도 별도의 하드웨어 스레드에 의해 동시에 실행될 수 있다.

스레딩 모델

1:1 (커널 수준 스레딩)

사용자가 생성한 스레드와 커널의 스케줄링 가능한 엔티티가 1:1로 대응하는 방식^[13]은 가장 단순한 스레딩 구현이다. OS/2와 Win32는 처음부터 이 방식을 사용했으며, 리눅스에서는 GNU C 라이브러리가 (NPTL 또는 이전의 LinuxThreads를 통해) 이 방식을 구현한다. 이 방식은 솔라리스, NetBSD, FreeBSD, macOS, iOS에서도 사용된다.

M:1 (사용자 수준 스레딩)

M:1 모델은 모든 애플리케이션 수준 스레드가 하나의 커널 수준 스케줄링 엔티티에 매핑됨을 의미한다.^[13] 커널은 애플리케이션 스레드에 대해 전혀 알지 못한다. 이 방식에서는 문맥 교환이 매우 빠르게 수행될 수 있으며, 스레딩을 지원하지 않는 단순한 커널에서도 구현될 수 있다. 그러나 주요 단점 중 하나는 멀티스레드 프로세서나 멀티프로세서 컴퓨터의 하드웨어 가속 이점을 얻을 수 없다는 것이다. 즉, 동시에 스케줄링되는 스레드가 하나뿐이다.^[13] 예를 들어, 스레드 중 하나가 I/O 요청을 실행해야 하는 경우 전체 프로세스가 차단되고 스레딩 이점을 사용할 수 없다. GNU Portable Threads와 State Threads는 사용자 수준 스레딩을 사용한다.

M:N (하이브리드 스레딩)

M:N은 M개의 애플리케이션 스레드를 N개의 커널 엔티티(또는 "가상 프로세서")에 매핑한다.^[13] 이는 커널 수준("1:1")과 사용자 수준("N:1") 스레딩 사이의 타협안이다. 일반적으로 "M:N" 스레딩 시스템은 커널 코드와 사용자 공간 코드 모두를 변경해야 하므로 커널 스레드나 사용자 스레드보다 구현하기가 훨씬 복잡하다. M:N 구현에서 스레딩 라이브러리는 가용한 스케줄링 가능 엔티티에 사용자 스레드를 스케줄링할 책임을 진다. 이를 통해 시스템 호출을 피할 수 있어 스레드의 문맥 교환이 매우 빨라진다. 그러나 이는 복잡성을 증가시키고 우선순위 역전 가능성을 높이며, 사용자 공간 스케줄러와 커널 스케줄러 간의 광범위하고 비용이 많이 드는 조정 없이는 최적화되지 않은 스케줄링을 초래할 수 있다.

하이브리드 구현 예시

NetBSD 네이티브 POSIX 스레드 라이브러리 구현의 이전 버전에서 사용된 스케줄러 활성화 (1:1 커널 또는 사용자 공간 구현 모델과 대조되는 M:N 모델)
솔라리스 운영체제의 이전 버전에서 사용된 경량 프로세스
PM2 프로젝트의 Marcel
Tera-Cray MTA-2용 운영체제
하스켈 언어용 글래스고 하스켈 컴파일러(GHC)는 운영체제 스레드 위에서 스케줄링되는 경량 스레드를 사용한다.

유닉스 시스템의 스레딩 모델 역사

SunOS 4.x는 경량 프로세스 또는 LWP를 구현했다. NetBSD 2.x+ 및 DragonFly BSD는 LWP를 커널 스레드로 구현한다(1:1 모델). SunOS 5.2부터 SunOS 5.8까지, 그리고 NetBSD 2부터 NetBSD 4까지는 각 커널 스레드에서 하나 이상의 사용자 수준 스레드를 다중화하는 2계층 모델(M:N 모델)을 구현했다. SunOS 5.9 이후와 NetBSD 5는 사용자 스레드 지원을 제거하고 1:1 모델로 복귀했다.^[14] FreeBSD 5는 M:N 모델을 구현했다. FreeBSD 6은 1:1과 M:N을 모두 지원했으며 사용자는 /etc/libmap.conf를 사용하여 특정 프로그램에 사용할 모델을 선택할 수 있었다. FreeBSD 7부터는 1:1이 기본값이 되었다. FreeBSD 8은 더 이상 M:N 모델을 지원하지 않는다.

단일 스레드 vs 멀티스레드 프로그램

컴퓨터 프로그래밍에서 단일 스레딩은 한 번에 하나의 기계어 명령어를 처리하는 것이다.^[15] 변수의 의미론과 프로세스 상태의 공식 분석에서 단일 스레딩이라는 용어는 다르게 사용되어 함수형 프로그래밍 커뮤니티에서 흔히 볼 수 있는 "단일 스레드 내에서의 역추적"을 의미할 수 있다.^[16]

멀티스레딩은 주로 다중작업 운영체제에서 발견된다. 멀티스레딩은 하나의 프로세스 컨텍스트 내에 여러 스레드가 존재할 수 있도록 하는 널리 퍼진 프로그래밍 및 실행 모델이다. 이러한 스레드들은 프로세스의 리소스를 공유하지만 독립적으로 실행될 수 있다. 스레드 프로그래밍 모델은 개발자에게 병행 실행에 대한 유용한 추상화를 제공한다. 멀티스레딩은 또한 멀티프로세싱 시스템에서 병렬 실행을 활성화하기 위해 하나의 프로세스에 적용될 수 있다.

멀티스레딩 라이브러리는 일반적으로 함수를 매개변수로 받아 새 스레드를 생성하는 함수 호출을 제공한다. 그러면 전달된 함수를 실행하기 시작하고 함수가 반환될 때 종료되는 병행 스레드가 생성된다. 스레드 라이브러리는 데이터 동기화 기능도 제공한다.

스레드와 데이터 동기화

동일한 프로세스의 스레드들은 동일한 주소 공간을 공유한다. 이를 통해 병행 실행되는 코드가 긴밀하게 결합되고 프로세스 간 통신의 오버헤드나 복잡성 없이 편리하게 데이터를 교환할 수 있다. 그러나 스레드 간에 공유될 때, 단순한 데이터 구조조차도 업데이트하는 데 둘 이상의 CPU 명령어가 필요한 경우 경쟁 상태에 취약해진다. 두 스레드가 동시에 데이터 구조를 업데이트하려고 시도하다가 예기치 않게 변경되는 것을 발견할 수 있다. 경쟁 상태로 인한 버그는 재현하고 격리하기가 매우 어려울 수 있다.

이를 방지하기 위해 스레딩 애플리케이션 프로그래밍 인터페이스(API)는 동시 접근으로부터 데이터 구조를 잠금하기 위해 뮤텍스와 같은 동기화 기본 요소를 제공한다. 단일 프로세서 시스템에서 잠긴 뮤텍스를 마주친 스레드는 잠들어야 하며 따라서 문맥 교환을 트리거한다. 멀티프로세서 시스템에서는 스레드가 스핀락에서 뮤텍스를 폴링할 수 있다. 이 두 경우 모두 성능을 저하시키고 특히 잠금 세분성이 너무 세밀할 경우 대칭형 다중 처리(SMP) 시스템의 프로세서들이 메모리 버스를 놓고 경쟁하게 만들 수 있다.

기타 동기화 API에는 조건 변수, 임계 구역, 세마포어, 모니터가 포함된다.

스레드 풀

스레드와 관련된 인기 있는 프로그래밍 패턴은 시작 시 설정된 수의 스레드가 생성되어 태스크가 할당되기를 기다리는 스레드 풀 패턴이다. 새로운 태스크가 도착하면 스레드가 깨어나 태스크를 완료하고 다시 대기 상태로 돌아간다. 이는 수행되는 모든 태스크에 대해 비용이 많이 드는 스레드 생성 및 파괴 함수를 피하고, 스레드 관리 책임을 애플리케이션 개발자에게서 라이브러리나 스레드 관리에 더 적합한 운영체제로 넘긴다.

모든 스레드가 바쁘면 스레드를 사용할 수 있을 때까지 추가 작업 항목이 큐에 배치된다.^[17]

멀티스레드 프로그램 vs 단일 스레드 프로그램 장단점

멀티스레드 애플리케이션은 단일 스레드 애플리케이션에 비해 다음과 같은 장점이 있다.

응답성: 멀티스레딩을 통해 애플리케이션이 입력에 계속 응답할 수 있다. 단일 스레드 프로그램에서 메인 실행 스레드가 오래 걸리는 작업으로 인해 차단되면 전체 애플리케이션이 멈춘 것처럼 보일 수 있다. 이러한 오래 걸리는 작업을 메인 실행 스레드와 병행하여 실행되는 워커 스레드로 옮기면 백그라운드에서 작업을 실행하면서도 애플리케이션이 사용자 입력에 계속 응답할 수 있다. 반면에 대부분의 경우 멀티스레딩만이 프로그램의 응답성을 유지하는 유일한 방법은 아니며, 비차단 I/O 및 유닉스 시그널을 사용하여 유사한 결과를 얻을 수 있다.^[18]
병렬화: 멀티코어 또는 멀티 CPU 시스템을 사용하려는 애플리케이션은 멀티스레딩을 사용하여 데이터와 태스크를 병렬 하위 태스크로 나누고 기반 아키텍처가 스레드 실행 방식을 관리하도록 할 수 있다. 즉, 하나의 코어에서 병행하거나 여러 코어에서 병렬로 실행하는 것이다. CUDA, OpenCL, DirectX 12와 같은 GPU 컴퓨팅 환경은 수십에서 수백 개의 스레드가 데이터 전반에 걸쳐 병렬로 많은 수의 코어 위에서 실행되는 멀티스레딩 모델을 사용한다. 이는 시스템 활용도를 높이고 (동기화 비용이 이점을 상쇄하지 않는다는 전제하에) 프로그램 실행 속도를 빠르게 할 수 있다.

멀티스레드 애플리케이션은 다음과 같은 단점이 있다.

동기화 복잡성 및 관련 버그: 스레드 프로그램의 전형인 공유 리소스를 사용할 때 프로그래머는 경쟁 상태 및 기타 직관적이지 않은 동작을 피하기 위해 주의해야 한다. 데이터가 올바르게 조작되려면 데이터를 올바른 순서로 처리하기 위해 스레드들이 시간에 맞춰 랑데부해야 하는 경우가 많다. 또한 스레드는 공통 데이터가 한 스레드에서 수정되는 동안 다른 스레드에서 읽거나 덮어쓰이지 않도록 상호 배제 작업(보통 뮤텍스를 사용하여 구현됨)이 필요할 수 있다. 이러한 기본 요소를 부주의하게 사용하면 교착 상태, 라이브락 또는 리소스를 두고 경쟁이 발생할 수 있다. 또한 멀티스레딩은 RAM을 포함한 시스템 리소스 사용량을 증가시킬 수 있다.^[19] 에드워드 A. 리가 썼듯이: "스레드는 순차적 계산에서 작은 단계처럼 보이지만 사실 거대한 단계를 나타낸다. 스레드는 순차적 계산의 가장 본질적이고 매력적인 속성인 이해 가능성, 예측 가능성, 결정론을 버린다. 계산 모델로서의 스레드는 매우 비결정적이며, 프로그래머의 작업은 그러한 비결정론을 솎아내는 것이 된다."^[20]
테스트 불가능함: 일반적으로 멀티스레드 프로그램은 비결정적이므로 테스트할 수 없다. 다시 말해, 멀티스레드 프로그램은 테스트 시스템에서는 절대 나타나지 않고 프로덕션 환경에서만 나타나는 버그를 쉽게 가질 수 있다.^[21]^[20] 이는 스레드 간 통신을 특정하고 잘 정의된 패턴(예: 메시지 전달)으로 제한함으로써 완화될 수 있다.
동기화 비용: 최신 CPU에서 스레드 문맥 교환은 최대 100만 CPU 사이클까지 비용이 들 수 있으므로^[22] 효율적인 멀티스레딩 프로그램을 작성하는 것은 어렵다. 특히 스레드 간 동기화가 너무 빈번하지 않도록 주의를 기울여야 한다.

프로그래밍 언어 지원

많은 프로그래밍 언어가 어느 정도 수준에서 스레딩을 지원한다.

IBM PL/I(F)는 이미 1960년대 후반에 멀티스레딩(멀티태스킹이라고 함) 지원을 포함했으며, 이는 최적화 컴파일러 및 이후 버전에서도 계속되었다. IBM 엔터프라이즈 PL/I 컴파일러는 새로운 모델의 "스레드" API를 도입했다. 두 버전 모두 PL/I 표준의 일부는 아니었다.
C 및 C++의 많은 구현은 스레딩을 지원하며 운영체제의 네이티브 스레딩 API에 대한 접근을 제공한다. 스레드 구현을 위한 표준화된 인터페이스는 C-함수 라이브러리 호출 집합인 POSIX 스레드(Pthreads)이다. 운영체제 공급업체는 원하는 대로 인터페이스를 구현할 수 있지만, 애플리케이션 개발자는 여러 플랫폼에서 동일한 인터페이스를 사용할 수 있어야 한다. 리눅스를 포함한 대부분의 유닉스 플랫폼은 Pthreads를 지원한다. 마이크로소프트 윈도우는 Process.h 인터페이스에 beginthread와 같은 멀티스레딩용 스레드 함수 세트를 자체적으로 가지고 있다.
자바, 파이썬, 닷넷 프레임워크 언어와 같은 일부 고급 (그리고 일반적으로 크로스 플랫폼인) 언어들은 런타임에서 스레딩 구현의 플랫폼별 차이를 추상화하면서 개발자에게 스레딩을 노출한다. 다른 여러 프로그래밍 언어 및 언어 확장들도 개발자에게 병행성과 스레딩 개념을 완전히 추상화하려고 시도한다(Cilk, OpenMP, 메시지 전달 인터페이스(MPI)). 일부 언어들은 병행성이나 스레드를 요구하지 않고 대신 순차적 병렬성을 위해 설계되었다(특히 GPU 사용 시) (Ateji PX, CUDA).
몇몇 인터프리터 프로그래밍 언어는 글로벌 인터프리터 락(GIL)으로 인해 스레딩과 병행성은 지원하지만 스레드의 병렬 실행은 지원하지 않는 구현(예: 루비용 루비 MRI, 파이썬용 C파이썬)을 가지고 있다. GIL은 인터프리터가 한 번에 두 개 이상의 스레드에서 애플리케이션 코드를 동시에 해석하는 것을 방지할 수 있는 인터프리터에 의해 유지되는 상호 배제 락이다. 이는 멀티코어 시스템에서의 병렬성을 효과적으로 제한한다. 또한 프로세서 바운드 스레드(프로세서가 필요한 스레드)에 대한 성능을 제한하지만, I/O 바운드나 네트워크 바운드 스레드에는 그렇게 큰 영향을 미치지 않는다. Thread 확장을 사용하는 Tcl과 같이 인터프리터 프로그래밍 언어의 다른 구현들은 데이터와 코드를 스레드 간에 명시적으로 "공유"해야 하는 아파트먼트 모델을 사용하여 GIL 제한을 피한다. Tcl에서 각 스레드는 하나 이상의 인터프리터를 가진다.
데이터 병렬 컴퓨팅을 위해 설계된 CUDA와 같은 프로그래밍 모델에서 스레드 배열은 메모리에서 데이터를 찾기 위해 ID만을 사용하여 동일한 코드를 병렬로 실행한다. 본질적으로, 애플리케이션은 각 스레드가 서로 다른 메모리 세그먼트에서 동일한 작업을 수행하여 병렬로 작동하고 GPU 아키텍처를 사용할 수 있도록 설계되어야 한다.
베릴로그와 같은 하드웨어 기술 언어는 매우 많은 수의 스레드를 지원하는(하드웨어 모델링용) 다른 스레딩 모델을 가지고 있다.

같이 보기

멀티스레딩

각주

↑ Lamport, Leslie (September 1979). “How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs” (PDF). 《IEEE Transactions on Computers》 C–28 (9): 690–691. Bibcode:1979ITCmp.100..690L. doi:10.1109/tc.1979.1675439. S2CID 5679366.
↑ Tanenbaum, Andrew S. (1992). 《Modern Operating Systems》. Prentice-Hall International Editions. ISBN 0-13-595752-4.
↑ Saltzer, Jerome Howard (July 1966). 《Traffic Control in a Multiplexed Computer System》 (PDF) (학위논문). 20쪽.
↑ 〈Mach: A New Kernel Foundation for UNIX Development〉 (PDF). 《1986 Summer USENIX Technical Conference & Exhibition Proceedings》. 1986. 93쪽.
↑ “Microsoft Operating System/2 Programmer's Guide” (PDF).
↑ “Standard for Information Technology--Portable Operating System Interface (POSIX(™)) - System Application Program Interface (API) Amendment 2: Threads Extension (C Language)” (영어). 《IEEE Standards Association》. 2025년 12월 11일에 확인함.
↑ “Pthread Win-32: Level of standards conformance”. 2006년 12월 22일. 2010년 6월 11일에 원본 문서에서 보존된 문서. 2010년 8월 29일에 확인함.
↑ Sutter, Herb (March 2005). “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”. 《닥터 돕스 저널》 30 (3).
↑ “Erlang: 3.1 Processes”.
↑ Ignatchenko, Sergey. 《Eight Ways to Handle Non-blocking Returns in Message-passing Programs: from C++98 via C++11 to C++20》. CPPCON. 2020년 11월 25일에 원본 문서에서 보존된 문서. 2020년 11월 24일에 확인함.
↑ Ferat, Manuel; Pereira, Romain; Roussel, Adrien; Carribault, Patrick; Steffenel, Luiz-Angelo; Gautier, Thierry (September 2022). 〈Enhancing MPI+OpenMP Task Based Applications for Heterogeneous Architectures with GPU support〉 (PDF). 《OpenMP in a Modern World: From Multi-device Support to Meta Programming.》. IWOMP 2022: 18th International Workshop on OpenMP. Lecture Notes in Computer Science. 3–16쪽. doi:10.1007/978-3-031-15922-0_1. ISBN 978-3-031-15921-3. S2CID 251692327.
↑ Iwasaki, Shintaro; Amer, Abdelhalim; Taura, Kenjiro; Seo, Sangmin; Balaji, Pavan. 《BOLT: Optimizing OpenMP Parallel Regions with User-Level Threads》 (PDF). The 28th International Conference on Parallel Architectures and Compilation Techniques.
1 2 3 4 Silberschatz, Abraham; Galvin, Peter Baer; Gagne, Greg (2013). 《Operating system concepts》 9판. Hoboken, N.J.: Wiley. 170–171쪽. ISBN 9781118063330.
↑ “Multithreading in the Solaris Operating Environment” (PDF). 2002. 2009년 2월 26일에 원본 문서 (PDF)에서 보존된 문서.
↑ Menéndez, Raúl; Lowe, Doug (2001). 《Murach's CICS for the COBOL Programmer》. Mike Murach & Associates. 512쪽. ISBN 978-1-890774-09-7.
↑ 틀:서적 인주
↑ “The managed thread pool - .NET Microsoft Learn”. Microsoft Learn. 2026년 4월 22일에 확인함.
↑ Ignatchenko, Sergey (August 2010). “Single-Threading: Back to the Future?”. 《오버로드》 (ACCU) (97): 16–19.
↑ Weisner, Rickey C. (March 2012). “How Memory Allocation Affects Performance in Multithreaded Programs”.
1 2 Lee, Edward (2006년 1월 10일). “The Problem with Threads”. UC 버클리.
↑ Ignatchenko, Sergey (August 2015). “Multi-threading at Business-logic Level is Considered Harmful”. 《오버로드》 (ACCU) (128): 4–7.
↑ 'No Bugs' Hare (2016년 9월 12일). “Operation Costs in CPU Clock Cycles”.

외부 링크

스레드/멀티스레딩
위키미디어 공용에 스레드 관련 미디어 분류가 있습니다.

[1] Lamport, Leslie (September 1979). “How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs” (PDF). 《IEEE Transactions on Computers》 C–28 (9): 690–691. Bibcode:1979ITCmp.100..690L. doi:10.1109/tc.1979.1675439. S2CID 5679366.

[tanenbaum199200-2] Tanenbaum, Andrew S. (1992). 《Modern Operating Systems》. Prentice-Hall International Editions. ISBN 0-13-595752-4.

[3] Saltzer, Jerome Howard (July 1966). 《Traffic Control in a Multiplexed Computer System》 (PDF) (학위논문). 20쪽.

[4] 〈Mach: A New Kernel Foundation for UNIX Development〉 (PDF). 《1986 Summer USENIX Technical Conference & Exhibition Proceedings》. 1986. 93쪽.

[5] “Microsoft Operating System/2 Programmer's Guide” (PDF).

[6] “Standard for Information Technology--Portable Operating System Interface (POSIX(™)) - System Application Program Interface (API) Amendment 2: Threads Extension (C Language)” (영어). 《IEEE Standards Association》. 2025년 12월 11일에 확인함.

[7] “Pthread Win-32: Level of standards conformance”. 2006년 12월 22일. 2010년 6월 11일에 원본 문서에서 보존된 문서. 2010년 8월 29일에 확인함.

[8] Sutter, Herb (March 2005). “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”. 《닥터 돕스 저널》 30 (3).

[9] “Erlang: 3.1 Processes”.

[10] Ignatchenko, Sergey. 《Eight Ways to Handle Non-blocking Returns in Message-passing Programs: from C++98 via C++11 to C++20》. CPPCON. 2020년 11월 25일에 원본 문서에서 보존된 문서. 2020년 11월 24일에 확인함.

[11] Ferat, Manuel; Pereira, Romain; Roussel, Adrien; Carribault, Patrick; Steffenel, Luiz-Angelo; Gautier, Thierry (September 2022). 〈Enhancing MPI+OpenMP Task Based Applications for Heterogeneous Architectures with GPU support〉 (PDF). 《OpenMP in a Modern World: From Multi-device Support to Meta Programming.》. IWOMP 2022: 18th International Workshop on OpenMP. Lecture Notes in Computer Science. 3–16쪽. doi:10.1007/978-3-031-15922-0_1. ISBN 978-3-031-15921-3. S2CID 251692327.

[12] Iwasaki, Shintaro; Amer, Abdelhalim; Taura, Kenjiro; Seo, Sangmin; Balaji, Pavan. 《BOLT: Optimizing OpenMP Parallel Regions with User-Level Threads》 (PDF). The 28th International Conference on Parallel Architectures and Compilation Techniques.

[OSConcepts-13] 1 2 3 4 Silberschatz, Abraham; Galvin, Peter Baer; Gagne, Greg (2013). 《Operating system concepts》 9판. Hoboken, N.J.: Wiley. 170–171쪽. ISBN 9781118063330.

[14] “Multithreading in the Solaris Operating Environment” (PDF). 2002. 2009년 2월 26일에 원본 문서 (PDF)에서 보존된 문서.

[15] Menéndez, Raúl; Lowe, Doug (2001). 《Murach's CICS for the COBOL Programmer》. Mike Murach & Associates. 512쪽. ISBN 978-1-890774-09-7.

[16] 틀:서적 인주

[17] “The managed thread pool - .NET Microsoft Learn”. Microsoft Learn. 2026년 4월 22일에 확인함.

[18] Ignatchenko, Sergey (August 2010). “Single-Threading: Back to the Future?”. 《오버로드》 (ACCU) (97): 16–19.

[19] Weisner, Rickey C. (March 2012). “How Memory Allocation Affects Performance in Multithreaded Programs”.

[Lee-20] 1 2 Lee, Edward (2006년 1월 10일). “The Problem with Threads”. UC 버클리.

[21] Ignatchenko, Sergey (August 2015). “Multi-threading at Business-logic Level is Considered Harmful”. 《오버로드》 (ACCU) (128): 4–7.

[22] 'No Bugs' Hare (2016년 9월 12일). “Operation Costs in CPU Clock Cycles”.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

v t e 병렬 컴퓨팅
일반	클라우드 컴퓨팅 고성능 컴퓨팅 클러스터 컴퓨팅 분산 컴퓨팅 그리드 컴퓨팅
병렬화 수준	비트 명령어 데이터 테스크
스레드	슈퍼스레딩 하이퍼스레딩
이론	암달의 법칙 구스타프슨의 법칙 비용 효과 카프-플랫 척도 감속 스피드업
구성 요소	프로세스 스레드 파이버 PRAM 명령어 윈도우
조정	멀티스레딩 메모리 일관성 캐시 일관성 메모리 배리어 동기화 애플리케이션 체크포인트
프로그래밍	모델(내재적 병렬성 외재적 병렬성 동시성) 플린의 분류학(SISD SIMD MISD MIMD) 스레드
하드웨어	다중 처리(대칭형 비대칭형) 메모리(NUMA COMA 분산 공유 분산 공유) SMT SMP MPP 슈퍼스칼라 벡터 프로세서 슈퍼컴퓨터 베어울프
API	POSIX 스레드 OpenMP PVM MPI UPC 스레딩 빌딩 블록 Boost 전역 배열 Charm++ Cilk/실크 플러스 코어레이 포트란 OpenCL CUDA
문제	처치 곤란 병렬 문제 그랜드 챌린지 문제 소프트웨어 락아웃 확장성 경쟁 상태 교착 상태 라이브락 결정론적 알고리즘 병렬 감속

전거 통제
국제	GND
국가	미국 프랑스 BnF 데이터 이스라엘
기타	예일 LUX