개요
일반적으로, Process와 Thread의 차이를 말할 때 다음과 같은 글을 마주할 수 있습니다.
(Process와 Thread의 차이 : https://nangmandeveloper.tistory.com/4)
위와 같은 글에서 Process와 Thread는 작업 단위, 저장 블록, 공유 자원, 상태 등으로 나누어집니다.
이 글에서는 이러한 부분보다 조금 더 근본적인 이야기를 해보고자 합니다.
단순히 사용하는 자원, Context Switching을 벗어나서, 공부하다가 마주치거나 스터디 중 마주친 질문에 대한 대답을 정리해 보도록 하겠습니다.
문제 소지가 있는 부분에 대한 의견은 언제나 환영입니다.
MultiCore의 등장
2005년, 인텔의 펜티엄 D시리즈와 AMD의 애슬론 64 X2시리즈가 발표되면서 멀티코어 시대의 문을 열었습니다.
이전의 CPU는 싱글코어만 있었기 때문에 CPU당 하나의 작업만 수행할 수 있습니다.
즉, 1CPU = 1작업인 것이 아니라 1CORE = 1작업인 것입니다.
그렇다면, 싱글코어 시절에는 정말 컴퓨터가 하나의 작업만 수행할 수 있었을까요?
아닙니다.
2005년 이전에도 윈도우즈 98과 같은 OS가 존재했고, 이러한 OS는 이미 수많은 작업들을 수행했습니다.
OS를 돌리며 게임 등의 작업을 수행했으므로 컴퓨터가 하나의 작업만 수행하는 것은 아닙니다.
단, 1개의 코어는 같은 시간에 여러 개의 작업을 수행할 수는 없습니다.
그렇다면 어떻게 여러 개의 작업을 같이 수행하는 것처럼 보이게 했을까요?
CPU Scheduling
CPU는 사람이 인지할 수 없을 정도의 빠른 속도로 작동합니다.
요즘 나오는 컴퓨터의 클럭은 3Ghz정도인데, 이는 초당 30억번의 신호를 발생시키는 수준입니다.
우리가 흔히 보는 모니터, 스마트폰의 화면은 초당 60Hz~144Hz를 사용합니다.
30억번은 이를 아득이 초과하는 수치로, 이를 3천만으로 나누어야 우리가 사용하는 모니터의 깜빡임 횟수와 비슷해집니다.
CPU도 이러한 사실을 이용해 각 작업들에 CPU를 순서대로 할당하고, 이 속도가 너무 빠르기 때문에 우리는 코어가 한 번에 여러 작업을 수행한다고 인지합니다.
이를 CPU Scheduling이라 부르는데, 이러한 CPU Scheduling은 두 가지 방식으로 나뉩니다.
1. 선점형
선점형 스케줄링의 경우, 운영체제가 필요하다고 판단하면 프로세스를 중단하고 다른 작업에 자원을 할당합니다.
때문에 해당 작업의 자원 독점을 막을 수 있지만, 작업이 끝나지 않았는데도 계속 작업을 교환하여 오버헤드가 발생할 가능성이 있습니다.
2. 비선점형
비선점형 스케줄링은 작업에 할당된 자원을 운영체제가 강제로 빼앗을 수 없습니다.
하나의 작업이 시작하면 끝을 볼 수 있다는 장점이 있으나, 그동안 다른 작업을 처리할 수 없다는 단점이 있습니다.
선점형 스케줄링, 비선점형 스케줄링의 방법에는 무엇이 있을까요?
선점형 스케줄링
1. Round Robin
각 작업들에 정해진 시간을 할당하고, CPU가 돌아가면서 이를 사용하며 해당 시간을 초과하면 다른 작업에 CPU자원을 할당하는 방식입니다.
정해진 시간을 Time Slice라 하며, 시간 초과시 타임아웃 인터럽트가 발생합니다.
P1 = 12초
P2 = 4초
P3 = 8초
실행 시간이 위와 같은 3가지 작업을 실행할 때, 실행 순서는 위 그림과 같을 것입니다.
CS는 Context Switching이 발생하는 순간입니다.
2. Sortest Remaining Time
작업은 정해진 시간만큼 CPU를 사용하는데, 남은 실행시간이 짧은 작업에 먼저 자원을 할당합니다.
라운드 로빈과 같은 작업을 수행하는 조건에서는, 순서가 이렇게 바뀔 것입니다.
3. Multi-level Queue
우선순위가 정해진 큐를 설정하고, 해당 순서대로 작업을 진행합니다.
큐 간의 이동이 불가능하기 때문에 낮은 우선순위 큐의 작업에 대한 기아 현상이 발생할 수 있습니다.
이와 같은 상황인 경우, P1 -> P2 -> P3순서대로 작업을 진행합니다.
4. Multi-level Feedback Queue
Multi-level Queue와 비슷하지만, 작업을 정해진 시간 내에 완료하지 못하는 경우 아래 순위의 큐로 내립니다.
이를 Aging이라 하는데, 이를 통해 기아를 방지할 수 있습니다.
비선점형 스케줄링
1. Firse Come First Served
작업 도착순으로 CPU를 할당합니다. 준비 큐에 도작한 순서대로 CPU에 자원을 할당합니다.
평균 대기시간이 길어지는 문제가 발생할 수 있습니다.
P1, P2, P3가 위와 같이 도착한다면, 도착한 순서대로 수행할 것입니다.
다만, P3는 4초만 실행하면 되는데도 20초를 기다려야 하는 문제가 있습니다.
이렇게 평균 대기시간이 길어지는 문제를 Convoy Effect라 합니다.
P1, P2, P3의 대기시간은 각각 0초, 12초, 20초이고, 평균 대기시간은 10.666... 초입니다.
2. Shorest Job First
실행시간이 짧다고 추천되는 작업 먼저 자원을 할당하는 스케줄링 알고리즘입니다.
P1, P2, P3가 순서대로 도착한다면, 먼저 P1이 도착했으므로 먼저 수행될 것입니다.
이후 P2, P3가 도착하는데 P3의 실행시간이 짧으므로 P3를 먼저 수행합니다.
P1, P2, P3의 대기시간은 각각 0초, 12초, 16초이고, 평균 대기시간은 9.333... 초입니다.
이는 FCFS알고리즘보다 짧은 대기시간임을 알 수 있습니다.
다만, 실행시간이 긴 프로세스는 대기시간이 계속 뒤로 밀리는 Starvation문제가 발생할 수 있습니다.
3. Highest Response-ratio Next
우선순위 = (대기시간 + 실행시간) / 실행시간
위의 공식을 이용하여 우선순위를 지정하고 실행합니다.
| 작업 | 대기시간 | 실행시간 |
| P1 | 5초 | 12초 |
| P2 | 8초 | 8초 |
| P3 | 10초 | 4초 |
위와 같이 대기시간과 실행시간이 지정되어 있다면
P1 우선순위 = (5 + 12) / 12 = 1.41666...
P2 우선순위 = (8 + 8) / 8 = 2
P3 우선순위 = (10 + 4) / 4 = 3.5
우선순위가 높은 순서대로, P3 -> P2 -> P1을 진행할 것입니다.
Context Switching
지금까지 CPU가 어떠한 순서로 작업을 수행하는지 알아보았습니다.
또, Process와 Thread의 Context Switching을 배웠다면 해당 작업이 교체되는 순간 Context Switching이 발생한다는 것을 알 수 있습니다.
Process는 PCB에 이전 정보를 저장하고 다음 프로세스를 가져오고, Thread는 TCB에 이전 정보를 저장하고...
그렇다면, CPU에서 다음 작업을 가져올 때 Process Context Switcing이 발생할까요? Thread Context Switching이 발생할까요?
CPU Scheduling은 많은 사람들이 알고 있고, 또한 컴퓨터과학을 공부할 때 짚고 넘어가는 부분입니다.
CPU 스케줄링은 기본적으로 수행할 작업이 있어야 발생합니다.
CPU에게 누군가 작업을 던져줘야 한다는 것입니다.
CPU에 작업을 던져주는 주체는 무엇일까요?
Windows, Linux, Unix, RTOS와 같은 운영체제일 것입니다.
그렇다면, OS는 어떠한 형태로 CPU에게 작업을 줄까요?
OS Scheduling
3.2. cpu Red Hat Enterprise Linux 6 | Red Hat Customer Portal
Access Red Hat’s knowledge, guidance, and support through your subscription.
access.redhat.com
Redhat의 리눅스, RHEL에서는 CPU resource에 대한 예약. OS가 CPU에 줄 작업을 예약하는 스케줄러로 다음과 같은 스케줄러를 사용함을 알 수 있습니다.
1. Completely Fair Scheduler
작업의 우선순위 / 가중치 또는 cgroup에 할당된 공유에 따라 cgroup간에 할당되는 CPU시간을 비례적으로 나누는 스케줄러입니다.
queue가 아닌 red-black트리를 기반으로 작업별 실행시간을 저장하고, 이에 따라 우선순위를 결정합니다.
자세한 내용은 아래 글을 참조하시면 됩니다.
https://dataonair.or.kr/db-tech-reference/d-lounge/technical-data/?mod=document&uid=236896
Linux 2.6 Completely Fair Scheduler 살펴보기
Linux 2.6 Completely Fair Scheduler 살펴보기 2.6.23 이후 공평한 CPU 액세스 제공 요약: 작업 스케줄러는 모든 운영 체제의 주요 부분이며 Linux에서는 이 영역을 꾸준히 혁신적으로 발전시키고 있습니다.
dataonair.or.kr
2. RealTime Scheduler
RealTime Scheduler에서는 실시간 작업이 사용할 수 있는 CPU시간을 지정합니다.
RT Scheduler는 한 시점에 하나의 작업이 실행되도록 하며, 높은 우선순위부터 순차적으로 실행됩니다.
First In First Out방식 또는 Round Robin방식을 골라 선택할 수 있습니다.
다음은 loyola university chicaho의 교육자료입니다.
https://os.cs.luc.edu/scheduling.html
Process/Thread Scheduling | Operating Systems: updated 11 Jan 2024
Average Response Time: If overhead is 5ms, quantum, is 20ms, and 5 active processes exist, the time between runs will be: (overhead + quantum) * (runnable processes - 1) = 100ms. If the quantum is reduced to 10ms, then the time between runs will be: 60ms
os.cs.luc.edu
여기서 Kernel Mode, User Mode로 스케줄러를 분류한 모습을 볼 수 있습니다.
또한, RHEL linux의 스케줄러 외의 방식도 확인할 수 있습니다.
강의 자료를 확인하면, Linux와 Windows등의 OS에서는 스케줄링을 할 때 프로세스 단위로 하는 것을 볼 수 있습니다.
즉, OS의 작업단위는 기본적으로 프로세스이고, 프로세스별로 스케줄링을 한 뒤 이를 CPU에 전달합니다.
(물론, CPU 스케줄링을 OS가 진행하기 때문에 OS느 프로세스, 스레드 스케줄링을 모두 한다고도 볼 수 있을 것입니다.)
CPU는 이렇게 전달된 프로세스를 받고, 해당 프로세스 내에 적재된 스레드들을 실행하는 것입니다.
때문에 CPU의 작업단위는 스레드라고 볼 수 있습니다.
정리
이전에 보았던 관점과는 달리, 이번 글에서는 프로세스와 스레드의 Context Switching이 언제 발생하는지를 알아보았습니다.
각 운영체제와 CPU별로 모두 다른 스케줄러를 갖고 있고, 커널 모드, 유저 모드 등 다양한 개념이 있으며 스레드의 종류도 많기 때문에(green thread, kernel thread, user thread...)단언할 수는 없지만, 어떠한 상황에서 어떠한 Context Switching이 발생하는지 이해를 돕기 위해 글을 작성했습니다.
IBM의 운영체제인 I의 공식 문서에서는 다음과 같은 말을 하고 있습니다.
" 프로세스는 프로그램의 메모리와 자원을 담는 컨테이너이다. "
" 프로세스에는 프로그램이 코드를 실행하는 스레드가 있고, 첫 번째 스레드를 초기 스레드라 한다. "
즉, 프로세스는 프로그램을 실행하기 위한 자원을 담는 구조(도시락)로 볼 수 있으며
스레드는 프로그램의 주요 서비스 로직(샌드위치, 빵, 후식 ...)이고
프로세스에 담긴 자원들은 스레드(샌드위치)가 담긴 정보, PID(도시락 구별정보), 상태(비었다. 먹을 수 있다, 뚜껑이 열렸다 ...), PC(먹던 샌드위치의 주소) 등이라 할 수 있을 것입니다.
해당 공식 문서의 링크 첨부하고 글 마치도록 하겠습니다.
의견은 댓글로 달아주시면 참고하도록 하겠습니다.
https://www.ibm.com/docs/en/i/7.1?topic=applications-threads-i
Threads on IBM i
All programs have at least one thread, referred to as the initial thread. In a program with multiple threads, each thread runs its code independently of the other threads in the program. A process is the container for the memory and resources of the progra
www.ibm.com
개요
일반적으로, Process와 Thread의 차이를 말할 때 다음과 같은 글을 마주할 수 있습니다.
(Process와 Thread의 차이 : https://nangmandeveloper.tistory.com/4)
위와 같은 글에서 Process와 Thread는 작업 단위, 저장 블록, 공유 자원, 상태 등으로 나누어집니다.
이 글에서는 이러한 부분보다 조금 더 근본적인 이야기를 해보고자 합니다.
단순히 사용하는 자원, Context Switching을 벗어나서, 공부하다가 마주치거나 스터디 중 마주친 질문에 대한 대답을 정리해 보도록 하겠습니다.
문제 소지가 있는 부분에 대한 의견은 언제나 환영입니다.
MultiCore의 등장
2005년, 인텔의 펜티엄 D시리즈와 AMD의 애슬론 64 X2시리즈가 발표되면서 멀티코어 시대의 문을 열었습니다.
이전의 CPU는 싱글코어만 있었기 때문에 CPU당 하나의 작업만 수행할 수 있습니다.
즉, 1CPU = 1작업인 것이 아니라 1CORE = 1작업인 것입니다.
그렇다면, 싱글코어 시절에는 정말 컴퓨터가 하나의 작업만 수행할 수 있었을까요?
아닙니다.
2005년 이전에도 윈도우즈 98과 같은 OS가 존재했고, 이러한 OS는 이미 수많은 작업들을 수행했습니다.
OS를 돌리며 게임 등의 작업을 수행했으므로 컴퓨터가 하나의 작업만 수행하는 것은 아닙니다.
단, 1개의 코어는 같은 시간에 여러 개의 작업을 수행할 수는 없습니다.
그렇다면 어떻게 여러 개의 작업을 같이 수행하는 것처럼 보이게 했을까요?
CPU Scheduling
CPU는 사람이 인지할 수 없을 정도의 빠른 속도로 작동합니다.
요즘 나오는 컴퓨터의 클럭은 3Ghz정도인데, 이는 초당 30억번의 신호를 발생시키는 수준입니다.
우리가 흔히 보는 모니터, 스마트폰의 화면은 초당 60Hz~144Hz를 사용합니다.
30억번은 이를 아득이 초과하는 수치로, 이를 3천만으로 나누어야 우리가 사용하는 모니터의 깜빡임 횟수와 비슷해집니다.
CPU도 이러한 사실을 이용해 각 작업들에 CPU를 순서대로 할당하고, 이 속도가 너무 빠르기 때문에 우리는 코어가 한 번에 여러 작업을 수행한다고 인지합니다.
이를 CPU Scheduling이라 부르는데, 이러한 CPU Scheduling은 두 가지 방식으로 나뉩니다.
1. 선점형
선점형 스케줄링의 경우, 운영체제가 필요하다고 판단하면 프로세스를 중단하고 다른 작업에 자원을 할당합니다.
때문에 해당 작업의 자원 독점을 막을 수 있지만, 작업이 끝나지 않았는데도 계속 작업을 교환하여 오버헤드가 발생할 가능성이 있습니다.
2. 비선점형
비선점형 스케줄링은 작업에 할당된 자원을 운영체제가 강제로 빼앗을 수 없습니다.
하나의 작업이 시작하면 끝을 볼 수 있다는 장점이 있으나, 그동안 다른 작업을 처리할 수 없다는 단점이 있습니다.
선점형 스케줄링, 비선점형 스케줄링의 방법에는 무엇이 있을까요?
선점형 스케줄링
1. Round Robin
각 작업들에 정해진 시간을 할당하고, CPU가 돌아가면서 이를 사용하며 해당 시간을 초과하면 다른 작업에 CPU자원을 할당하는 방식입니다.
정해진 시간을 Time Slice라 하며, 시간 초과시 타임아웃 인터럽트가 발생합니다.
P1 = 12초
P2 = 4초
P3 = 8초
실행 시간이 위와 같은 3가지 작업을 실행할 때, 실행 순서는 위 그림과 같을 것입니다.
CS는 Context Switching이 발생하는 순간입니다.
2. Sortest Remaining Time
작업은 정해진 시간만큼 CPU를 사용하는데, 남은 실행시간이 짧은 작업에 먼저 자원을 할당합니다.
라운드 로빈과 같은 작업을 수행하는 조건에서는, 순서가 이렇게 바뀔 것입니다.
3. Multi-level Queue
우선순위가 정해진 큐를 설정하고, 해당 순서대로 작업을 진행합니다.
큐 간의 이동이 불가능하기 때문에 낮은 우선순위 큐의 작업에 대한 기아 현상이 발생할 수 있습니다.
이와 같은 상황인 경우, P1 -> P2 -> P3순서대로 작업을 진행합니다.
4. Multi-level Feedback Queue
Multi-level Queue와 비슷하지만, 작업을 정해진 시간 내에 완료하지 못하는 경우 아래 순위의 큐로 내립니다.
이를 Aging이라 하는데, 이를 통해 기아를 방지할 수 있습니다.
비선점형 스케줄링
1. Firse Come First Served
작업 도착순으로 CPU를 할당합니다. 준비 큐에 도작한 순서대로 CPU에 자원을 할당합니다.
평균 대기시간이 길어지는 문제가 발생할 수 있습니다.
P1, P2, P3가 위와 같이 도착한다면, 도착한 순서대로 수행할 것입니다.
다만, P3는 4초만 실행하면 되는데도 20초를 기다려야 하는 문제가 있습니다.
이렇게 평균 대기시간이 길어지는 문제를 Convoy Effect라 합니다.
P1, P2, P3의 대기시간은 각각 0초, 12초, 20초이고, 평균 대기시간은 10.666... 초입니다.
2. Shorest Job First
실행시간이 짧다고 추천되는 작업 먼저 자원을 할당하는 스케줄링 알고리즘입니다.
P1, P2, P3가 순서대로 도착한다면, 먼저 P1이 도착했으므로 먼저 수행될 것입니다.
이후 P2, P3가 도착하는데 P3의 실행시간이 짧으므로 P3를 먼저 수행합니다.
P1, P2, P3의 대기시간은 각각 0초, 12초, 16초이고, 평균 대기시간은 9.333... 초입니다.
이는 FCFS알고리즘보다 짧은 대기시간임을 알 수 있습니다.
다만, 실행시간이 긴 프로세스는 대기시간이 계속 뒤로 밀리는 Starvation문제가 발생할 수 있습니다.
3. Highest Response-ratio Next
우선순위 = (대기시간 + 실행시간) / 실행시간
위의 공식을 이용하여 우선순위를 지정하고 실행합니다.
| 작업 | 대기시간 | 실행시간 |
| P1 | 5초 | 12초 |
| P2 | 8초 | 8초 |
| P3 | 10초 | 4초 |
위와 같이 대기시간과 실행시간이 지정되어 있다면
P1 우선순위 = (5 + 12) / 12 = 1.41666...
P2 우선순위 = (8 + 8) / 8 = 2
P3 우선순위 = (10 + 4) / 4 = 3.5
우선순위가 높은 순서대로, P3 -> P2 -> P1을 진행할 것입니다.
Context Switching
지금까지 CPU가 어떠한 순서로 작업을 수행하는지 알아보았습니다.
또, Process와 Thread의 Context Switching을 배웠다면 해당 작업이 교체되는 순간 Context Switching이 발생한다는 것을 알 수 있습니다.
Process는 PCB에 이전 정보를 저장하고 다음 프로세스를 가져오고, Thread는 TCB에 이전 정보를 저장하고...
그렇다면, CPU에서 다음 작업을 가져올 때 Process Context Switcing이 발생할까요? Thread Context Switching이 발생할까요?
CPU Scheduling은 많은 사람들이 알고 있고, 또한 컴퓨터과학을 공부할 때 짚고 넘어가는 부분입니다.
CPU 스케줄링은 기본적으로 수행할 작업이 있어야 발생합니다.
CPU에게 누군가 작업을 던져줘야 한다는 것입니다.
CPU에 작업을 던져주는 주체는 무엇일까요?
Windows, Linux, Unix, RTOS와 같은 운영체제일 것입니다.
그렇다면, OS는 어떠한 형태로 CPU에게 작업을 줄까요?
OS Scheduling
3.2. cpu Red Hat Enterprise Linux 6 | Red Hat Customer Portal
Access Red Hat’s knowledge, guidance, and support through your subscription.
access.redhat.com
Redhat의 리눅스, RHEL에서는 CPU resource에 대한 예약. OS가 CPU에 줄 작업을 예약하는 스케줄러로 다음과 같은 스케줄러를 사용함을 알 수 있습니다.
1. Completely Fair Scheduler
작업의 우선순위 / 가중치 또는 cgroup에 할당된 공유에 따라 cgroup간에 할당되는 CPU시간을 비례적으로 나누는 스케줄러입니다.
queue가 아닌 red-black트리를 기반으로 작업별 실행시간을 저장하고, 이에 따라 우선순위를 결정합니다.
자세한 내용은 아래 글을 참조하시면 됩니다.
https://dataonair.or.kr/db-tech-reference/d-lounge/technical-data/?mod=document&uid=236896
Linux 2.6 Completely Fair Scheduler 살펴보기
Linux 2.6 Completely Fair Scheduler 살펴보기 2.6.23 이후 공평한 CPU 액세스 제공 요약: 작업 스케줄러는 모든 운영 체제의 주요 부분이며 Linux에서는 이 영역을 꾸준히 혁신적으로 발전시키고 있습니다.
dataonair.or.kr
2. RealTime Scheduler
RealTime Scheduler에서는 실시간 작업이 사용할 수 있는 CPU시간을 지정합니다.
RT Scheduler는 한 시점에 하나의 작업이 실행되도록 하며, 높은 우선순위부터 순차적으로 실행됩니다.
First In First Out방식 또는 Round Robin방식을 골라 선택할 수 있습니다.
다음은 loyola university chicaho의 교육자료입니다.
https://os.cs.luc.edu/scheduling.html
Process/Thread Scheduling | Operating Systems: updated 11 Jan 2024
Average Response Time: If overhead is 5ms, quantum, is 20ms, and 5 active processes exist, the time between runs will be: (overhead + quantum) * (runnable processes - 1) = 100ms. If the quantum is reduced to 10ms, then the time between runs will be: 60ms
os.cs.luc.edu
여기서 Kernel Mode, User Mode로 스케줄러를 분류한 모습을 볼 수 있습니다.
또한, RHEL linux의 스케줄러 외의 방식도 확인할 수 있습니다.
강의 자료를 확인하면, Linux와 Windows등의 OS에서는 스케줄링을 할 때 프로세스 단위로 하는 것을 볼 수 있습니다.
즉, OS의 작업단위는 기본적으로 프로세스이고, 프로세스별로 스케줄링을 한 뒤 이를 CPU에 전달합니다.
(물론, CPU 스케줄링을 OS가 진행하기 때문에 OS느 프로세스, 스레드 스케줄링을 모두 한다고도 볼 수 있을 것입니다.)
CPU는 이렇게 전달된 프로세스를 받고, 해당 프로세스 내에 적재된 스레드들을 실행하는 것입니다.
때문에 CPU의 작업단위는 스레드라고 볼 수 있습니다.
정리
이전에 보았던 관점과는 달리, 이번 글에서는 프로세스와 스레드의 Context Switching이 언제 발생하는지를 알아보았습니다.
각 운영체제와 CPU별로 모두 다른 스케줄러를 갖고 있고, 커널 모드, 유저 모드 등 다양한 개념이 있으며 스레드의 종류도 많기 때문에(green thread, kernel thread, user thread...)단언할 수는 없지만, 어떠한 상황에서 어떠한 Context Switching이 발생하는지 이해를 돕기 위해 글을 작성했습니다.
IBM의 운영체제인 I의 공식 문서에서는 다음과 같은 말을 하고 있습니다.
" 프로세스는 프로그램의 메모리와 자원을 담는 컨테이너이다. "
" 프로세스에는 프로그램이 코드를 실행하는 스레드가 있고, 첫 번째 스레드를 초기 스레드라 한다. "
즉, 프로세스는 프로그램을 실행하기 위한 자원을 담는 구조(도시락)로 볼 수 있으며
스레드는 프로그램의 주요 서비스 로직(샌드위치, 빵, 후식 ...)이고
프로세스에 담긴 자원들은 스레드(샌드위치)가 담긴 정보, PID(도시락 구별정보), 상태(비었다. 먹을 수 있다, 뚜껑이 열렸다 ...), PC(먹던 샌드위치의 주소) 등이라 할 수 있을 것입니다.
해당 공식 문서의 링크 첨부하고 글 마치도록 하겠습니다.
의견은 댓글로 달아주시면 참고하도록 하겠습니다.
https://www.ibm.com/docs/en/i/7.1?topic=applications-threads-i
Threads on IBM i
All programs have at least one thread, referred to as the initial thread. In a program with multiple threads, each thread runs its code independently of the other threads in the program. A process is the container for the memory and resources of the progra
www.ibm.com
