[OS 공룡책] 4. Thread & Concurrency

 

 

하나의 프로그램에서도 여러가지 동작을 동시에 수행할 수 있다는 점에서 스레드가 필요하다

 

spring을 배우면서 그렇게 했던 스레드풀, 스택영역 등..이 이제 여기와 관련된 내용

 

멀티스레딩을 하면 좋은점은

- Responsiveness

    연속적인 응답을 가능하게 한다

- Resource Sharing

    스레드는 프로세스와 달리 메모리 공간을 공유하기 때문에 shared-memory나 message passing 방식보다 훨씬 쉽다

    좀더 정확히는 JVM 구조 공부했을 때처럼 힙영역, 메서드 영역을 공유한다고 보면 될 것 같다. (Thread Local같은 예외도 있다)

- Economy

    프로세스 생성보다 훨씬 저렴하다

    context swithching보다 thread switching이 overhead가 훨씬 적다

- scalability

 

 

 

하나의 프로세서에서는 이 멀티스레딩 구조가 쉬울텐데, 현대에는 멀티코어 시스템을 사용하기 때문에 훨씬 더 복잡해진다

즉, 여러개의 스레드가 물리적으로 동일한 시간에 돌아가는 parallel한 개념이 나오기 때문에 동시성 문제가 더 생기는 것

-> 이게 자바 고급편에서 주로 다뤘던 내용이다

 

 

어떤 문제가 생기냐면

- identifying tasks

    일을 쪼개서 각 스레드에게 어떤 일을 시킬것인지

- balance

    각 스레드에게 얼마나 일을 쪼개서 시킬것인지

- data splitting

- data dependency

- test and debugging

 

 

+ 분산시스템이 나오면서 이게 더 복잡해졌다고 첨언도 나온다,, 저번 학기에 지겹게 배웠던 분산시스템..

 

 

 

스레드 종류 

 

- user thread

    java에서 일반적으로 사용하는 스레드를 예시로 들 수 있겠다

- kernel thread

    시스템에 접근하기 위해 사용하는 native thread

 

 

다른 내용은 다 배운 기억이 잘 나는데 이건 기억이 전혀 안난다..? 기억을 못하는건가

이건 좀 자세하게 알아보자

 

user thread와 kernel thread의 관계에서는

- many to one model

    커널 스레드 하나가 여러개의 유저 스레드를 매핑

   

- one to one model

    하나의 커널 스레드가 하나의 유저 스레드를

- many to many model

 

 

 

이러면서 어플리케이션에서 커널 스레드를 쉽게 다루기 위한 pthread 개념이 나온다

유닉스 계열에서는 Posix thread이고

윈도우는 자체 윈도우 스레드가 있다고 한다

 

 

many to one 방식은 비효율적이고 멀티코어를 사용하기 힘들기 때문에 잘 사용하지 않고

대표적으로

자바에서 사용하는 방식이 one to one이고

GO언어에서 사용하는 방식이 many to many라고 한다

 

그럼 자바에서 스레드를 하나 늘릴때마다 OS 스레드도 하나 늘어나게 되는거고..

 

--> 너무 당연히 one to one이라고 생각했던 나를 반성하게 되는게

 

모니터링할때 os에 떠있는 스레드 개수가 스레드풀 개수랑 비슷하겠지라고 생각했다

이게 지금은 맞는 말이지만

 

만약 many to many 방식을 사용한다면 OS 스레드 개수는 서버의 스레드풀 개수에 비해 훨씬 적었을 것 같다

 

--> 이와 관련해 JAVA21에서 virtual thread 기능이 추가되었다고 한다

go routine처럼 many to many 매핑이 가능하다고 하는데,,

여태까지 왜 17썼지..? 정확하지는 않으니 나중에 따로 정리해보자