OS가 스레드 동시성을 보장하듯이 스케줄러는 비동기작업의 동시성을 보장함
그럼 병렬성은 어떻게 달성하느냐?
프로그램 스케줄러가 내부 판단하에 스레드를 생성하게 되면은 OS 스케줄러가 내부 판단 하에 스레드를 물리적 스레드와 병렬적으로 매칭했을 경우에만 병렬성이 달성됨.
즉 스케줄러가 단일스레드여도 병렬성은 안되고, 스레드를 생성해도 os 스케줄러가 단일코어로 작업시키면 병렬성은 달성이 안됨. 근데 중요한 것은 병렬성을 프로그래머가 판단해서 이래라 저래라 할 게 아니라는거임. 걍 병렬성은 생각 안하고 코드는 원래 하던대로 동시성만 고려하며 비동기적으로 짜면 됨.
프로그램 스케줄러가 무조건 스레드를 생성하지 않는 이유는, 스레드는 생성과 유지에 비용이 크고, 대부분의 경우 단일스레드로 처리할 때가 빠르기 때문임.
예) GO 언어의 고루틴 스케줄러는 대부분 단일스레드를 사용하지만 경우에 따라 멀티스레드를 사용한다.
고언어는 runtime.GOMAXPROCS 함수를 통해 고루틴이 생설할 수 있는 최대 스레드의 개수를 정할 수 있고, 기본값으로는 물리적 스레드(코어)의 개수로 설정되어 있다.
병렬적으로만 써야하는경우가 있을까? 병렬말고는 구현안되는것 같은거? - dc App
os 위에서 돌아가는경우로 있나요? 병렬하니깐 FPGA 생각나긴하는데 일반적인 프로세서 내부에서 그렇게 써먹는게있나요? - dc App
병렬적으로만 써야하는 경우는 없고 절대 그런 것을 기대해서도 안됨. 병렬성은 단순히 성능향상을 꾀하기 위한 용도로만 생각해야함
그렇구나 고마웡 - dc App
비동기 프로그래밍으로 코드를 짰으면 동시성만으로 만족해야지 실행속도가 빨라지는 병렬성까지 기대하면 안됨.
병렬성을 통한 속도 개선은 환경(코어 개수)에 따라서 충족될 수 있고 안될 수도 있는 덤이라고만 생각해야함.
c++의 async는 스레드를 생성하기 때문에 병렬성을 기대할 수 있음
MAXPROC 1로 써도 스케줄러는 내부적으로 멀티스레드 쓰는것 같던데 왜 그런생각했냐면 윈도우에서 COM이랑 연동했는데 중간에 끊겼다 말았다 하더라고 알고보니 com은 연결한 윈도우스레드랑만 연결되는데 고 런타임은 그걸 내부적으로 스케줄링하니까 끊어졌다 연결됬다 하는거였음 …
물리코어개수가 아니라 논리코어개수임