Sync/Async와 Blocking NonBlocking
예시
해야할 일
- 음악을 듣는다
- 코드를 친다
- 커피를 마신다
제약 사항
- 귀와 손은 동시에 사용을 하지 못한다.
- 두가지 작업을 완벽하게 작업을 할수는 없다.
음악을 들으면서 코딩을 못함
음악을 들어면서 커피 마시기를 못함
Parallelism
CPU를 추가하여 한 CPU1은 음악을 듣고 CPU2는 커피 마시기와 코딩을 할 수 있음
Concurrency
CPU2가 커피와 코딩을 하는 타이밍을 지정해줌
스케쥴링(Concurrency)
Preemtive scheduling
모든 작업들에 미리 일정 시간을 분배하여 스케쥴링
- 시간이 절대적 (스프린트가 끝나면 무조건 다음 칸반 진행)
- 현재 작업이 끝나지 않았더라도 멈추고 다른 작업을 진행
Copperactive scheduling
현재 실행되도 있는 작업이 결정권을 가지고 있음
- 작업이 절대적 (스프린트가 끝나더라도 현재 칸반 진행)
- 대기시간이 발생(Parse)하면 CPU에가 알려주고 CPU는 다음 작업을 진행
- 다른 PR이 merge가 되어야 진행할 수 있는 상황?
Thread
프로세스가 할당받은 자원을 이용하는 실행의 단위
OS Thread
레지스터, Stack은 별도
Code, Data, Heap 공유
- 장점
- 간단하다
- 사용하기 쉽다.
- 퍼포먼스가 좋다.
- Parallism에 자유롭다.
- 단점
- Stack을 꽤 많이 사용하게 된다. 따라서 동시에 대기중인 작업이 많은 경우 메모리가 부족해진다.
- OS로 인해 의도하지 않은 작업이 높은 우선 순위를 받을 수 있다.
- 많은 시스템 콜이 관여하게 된다. 이는 의도하지 않은 태스크가 많이 생길 수 있다.
Green Thread
어플리케이션 레벨에서의 스케쥴링 프레임 워크를 이용
heap영역을 할당 받음
ex) goroutine, tokio
os thread가 한개의 경우 user level에서 멀티스레드처럼 활용 가능
- 장점
- 사용 하기 쉽다. 이미 알려진 라이브러리들은 OS Thread와 비슷한 API들을 제공한다.
- 퍼포먼스가 좋다.
- 메모리를 많이 사용하더라도 문제가 적다.
- 모든 스레드들을 효과적으로 사용할 수 있다.
- 우선 순위를 사용자가 지정할 수 있다.
- 단점
런타임이 필요하고 이는 OS가 관리 하고 있는 일과 중복된다.
다양한 처리를 할 수 있는 유연한 방식으로 구현하기 어려울 수 있음.
<aside>
💡 OS Thread와 Green thread는 M:N관계이다.
</aside>
Async/sync vs Blocking/Non-blocking
- 코드 리뷰를 팀원에게 부탁하였다.
Blocking
팀원이 리뷰가 끝났다고 말해줄 떄 까지 아무것도 못함
Non-blocking
팀원이 리뷰가 끝나지 않았어도 다음 칸반을 진행
Sync
팀원이 리뷰가 끝났다고 말해줄 때 까지 기다림→ 대답에 따라 앞으로의 일 진행 사항이 바뀜
Async
다음 칸반을 진행하면서 기다림, → 대답에 따라 앞으로의 일 진행 사항이 바뀜
일 진행사항을 결정하는 것은 스케쥴러이다.
댓글