Non-blocking I/O와 Multi-threading은 바늘과 실이다.

비동기 입/출력을 시도하는 코드가 등장하면 거의 대부분 멀티스레딩 환경이 됩니다. 최소한 논리적으로 입출력처리와 다른 화면처리가 분리되는 구조를 갖는 정도는 따라옵니다. 해서 멀티스레딩과 비동기 입/출력을 하나로 묶었을 때 흔히 볼 수 있는 구조를 간략히 설명했습니다. 학습에 도움이 되면 좋겠습니다. 감사합니다. ^^

[@korean_huny]

안녕하세요 좋은 강의 잘 보고있습니다. 저는 현재 IT회사에서 근무중인 주니어 개발자입니다. 금일 업무를 진행하면서 주위 개발자와 이야기를 나누다 궁금한 점이 생겨 질문 드립니다. 다만 다소 잘못된 질문일 수 있으니 ㅠㅠ 양해를 구합니다. 질문은 다음과 같습니다. "싱글스레드의 비동기 I/O와 멀티프로세스 중 어떤 것이 더 빠르고 효율적인가 ?" 라는 이야기를 하다가 그렇다면 멀티프로세스에서 각각의 프로세스에 할당된 스레드가 비동기 처리를 하면 더욱 효과적인것이 아닌가 ? 하는 의문이 생겼습니다. 이렇게 처리를 하지 않는 이유를 저희는 데이터 선점의 문제, 동기화의 문제일 것이라고 추측하고 있는 상황입니다. 보다 정확한 답변을 구하고싶어 염치불구하고 댓글 달아봅니다. 감사합니다. 좋은 하루 보내셨으면 좋겠습니다. 😁

[@nullnull_not_eq_null]

음...상황에 따라 다르긴 하겠지만...싱글 스레드 + 비동기 I/O가 멀티스레드 + 동기 I/O보다 더 높은 성능을 낼 가능성이 높습니다. 범용 OS에서 입/출력의 주체는 OS입니다. 제 아무리 User mode 프로세스가 애써봤자 OS를 이길 수는 없습니다. 다만 멀티스레드 + 비동기 I/O 조합은 이길 방법이 없겠습니다. 소켓 통신 기법 중 최고봉으로 쳐주는 IOCP가 정확히 멀티스레드 + 비동기 I/O 이기 때문입니다. 물론 플러스 알파가 있긴 합니다. (대표적으로 스레드 풀 및 관리체계가 그렇습니다.) 물론 이 경우 동기화 이슈가 발생하며 무엇보다 OS의 Callback을 수신하고 처리하는 문제를 비롯해 논리적으로 생각 할 것이 많긴 합니다. 당연히 동기화 이슈도 따라옵니다. 개인적인 의견이지만 동기화보다 더 머리 아픈 것은 사용자 세션 객체 관리나 메모리 관리 입니다. 적절한 해체 타이밍을 계산하기가 생각보다 어렵습니다. 결국 가비지 컬렉터를 구현하는 방식으로 마무리 했던 기억이 있습니다. 짧은 답변이지만 참고하시기 바랍니다. 건투를 빕니다!

[@멍충의심장]

컴공과 1학년 C를 배울 초반에는 과연 "컴퓨터공학과"가 적성에 맞을까 너무 고민이 되었던 기억이 있는데, 어느새 선생님 강의를 듣게된 지도 2-3년이 흘렀네요. 그 사이에 컴퓨터공학에 정말 깊이 빠진 것 같고(실력과 별개로), 처음 시작할 때 참 좋은 선생님을 만나서 복을 많이 받은 것 같아서 다행이고 감사합니다 :) 하지만 아쉬운 건, 곧 군입대를 기다리고 있는 지라 이 재미있는 공부를 당분간은 유튜브나 강의가 아니라 전공서적 가지고서만 해야할 듯 싶어요. 훈련소에서 태블릿이나 휴대폰은 사용할 수가 없으니까요 ㅎㅎ 그래도, 독하게 시작하는 C프로그래밍하고, 공룡책 운영체제 두 개 정도 가져가서 이번 기회에 틈틈이 복습 / 공부하려고 해요! 훈련소 수료하고... 자대배치 받고... 또 개발 공부를 적극적으로 다시 시작할 즈음, 강의도 다시 듣겠습니다 :) 아 멤버십은 끊지 않고 계속 구독하려구요 ㅎㅎ 나라 지키는 돈이랍시고 어줍잖게 명품 사입는 것보다 더 값진 돈인 것 같아서요! 여하튼! 2개월 정도는, 그간 배운 내용을 저 혼자 소화해보는 시간을 가져볼까 해요! 컴공을 사랑하게 해주셔서, 개발에 의미있는 꿈을 갖게 해주셔서 너무너무 감사드립니다 ㅎㅎ 군대 잘 다녀오겠습니당 :)

[@nullnull_not_eq_null]

영상으로 답변을 드립니다. ^^;; kzbin.info/www/bejne/gJS8pK2Fm8RseLM

[@toby_MusicProgrammer]

군대 잘 다녀오세요! 저는 군대에서도 사지방 이용하면서 코딩 공부 잘 할 수 있었어요! 개인정비 시간 + 연등시간까지 합하면 평일에도 꽤 많은 시간을 사지방에서 보낼 수 있고 백엔드 부분도 GCP나 AWS 이용해서 가상 머신 이용하시면 손쉽게 연습하실 수 있어요! 특히 GCP에 App Engine 이라는 기능이 있는데 거기 웹 IDE 가 꽤 괜찮더라고요 Vim 으로 연습하는것 보다야 백배 낫습니다 ㅎㅎ 군대 잘 갔다오시고 가서도 충분히 공부 많이 하실 수 있으니 걱정하지 마세요!

[@nick6267]

너무 좋네요ㅎㅎ보통 프로그래밍적으로 설명하는 것을 넘어서서 os레벨에서까지 같이 들으니까요

[@nullnull_not_eq_null]

좋은 평가 감사합니다. 이렇게 내부적인 흐름까지 같이 알아 두면 다양한 현상을 이해하는데 도움이 되지요. 열공하세요~~~! ^^

[@chrisshim2488]

명강의 감사합니다. actor model framework를 사용하면 높은 추상화로 동시성을 해결 할 수 있지요.

[@nullnull_not_eq_null]

네, 맞습니다. 그러고 보니 UML 강의도 만들어야 하고...디자인 패턴도 해야 하고...산더미네요. 좋은 의견 감사합니다. ^^

[@갈가마구]

프로세스간 동작하는 방식이 쓰레드간 동작 방식이랑 비슷한가 보네요.. 물론 쓰레드간은 같은 주소를 공유하고 있으니 차이는있겠지만...쓰레드간에도 큐가 있어 정보를 주고 받는데 이용을 하는군요...음...갈수록 복잡해 지네요 .. 감사합니다. 😅

[@nullnull_not_eq_null]

동기화 객체 + 이벤트(시그널) + 큐...이 셋은 늘 따라다닙니다. ^^

[@명익-x1s]

안녕하세요. 영상 설명란에 "비동기 입출력을 시도하는 코드가 등장하면 거의 대부분 멀티스레딩 환경이 됩니다" 라고 말씀하신 부분에 대해 궁금한게 생겨 질문드립니다. "거의 대부분" 이라고 표현하신 것에 대해, 단일 스레드로만 이루어진 프로세스가 있다고 가정했을때 이 프로세스의 스레드를 블로킹하지 않고 파일 입출력을 수행할 수 있는 방법이 존재하나요? 설령 운영체제를 통해 가능하다 해도 운영체제 또한 다수의 프로세스로 이루어진 거대한 환경일텐데, 그 환경의 특정 스레드를 블락하지 않고 파일 입출력이 가능한가 하는 생각이 듭니다. 추가로 멀티스레딩 환경이라고 표현하신게 애플리케이션이 여러 스레드를 가지고 있다는 의미인지, 시스템이 여러 스레드를 다룰 수 있다는 의미인지도 설명해주시면 감사하겠습니다. (Node.js 를 비롯한 많은 런타임이나 라이브러리 등은 독자적인 thread pool 등을 이용해 입출력 작업을 위임하여 메인 스레드 대신 블락 되도록 하는 방식으로 동작한다고 이해하고 있습니다)

[@nullnull_not_eq_null]

네, 가능합니다. 하지만 그렇게 싱글 스레딩으로 처리하려면 사실 상 동기모드로 작성한 것과 큰 차이가 없어집니다. 따라서 사실 상 아무도 그렇게 하지는 않습니다. 그러나 혹시라도 제가 모르는 예외가 있을 수도 있겠다 싶어 여유를 두고 '거의 대부분'이라는 표현을 사용했습니다. 그리고 커널 영역는 제외하고 의미를 생각하는 것이 좋겠습니다. 핵심은 입/출력을 실제로 수행하는 주체는 OS이고 그렇기에 비동적으로 OS에게 처리를 맡기는 방식이 더 놓은 성능을 보장한다는 것을 아는 것이 중요하겠습니다. 끝으로 멀티스레딩 환경이란 한 프로세스 내부에 여러 스레드가 있는 경우 입니다. 시스템 수준으로 볼 수는 없겠습니다. 그리고 Node.js는 V8 엔진을 사용합니다. 따라서 입/출력 성능과 관련한 이야기는 결국 엔진수준에서 결정될 것으로 보입니다. 참고하시기 바랍니다. :)

[@miseongYoutube]

안녕하세요. 강의를 듣다가 궁금한 점이 생겨 질문드립니다! 8:38 에서 쓰레드 1이 요청한 '파일 읽는 작업이 비동기'로 진행된다고 하였는데, 파일 읽기와 영상 처리 그리고 송신의 작업들을 각각 쓰레드로 분리하여 작업을 한다면, 굳이 하나의 쓰레드에서 파일 읽는 작업을 비동기로 처리할 필요가 없지 않나요? 하나의 쓰레드가 하나의 I/O 작업을 하도록 멀티 쓰레딩으로 구현했기 때문에 I/O 작업을 하는 동안 블락되어 기다려도 비동기 처리와 같은 성능을 낼 것 같다는 생각이 들었습니다!

[@nullnull_not_eq_null]

클라이언트라면 큰 차이가 없을 수 있습니다. 그러나 서버는 이야기가 다릅니다. 작은 차이지만 입출력 병목을 해결하기 위해 그 차이를 줄여주지 않으면 성능이 나오질 않습니다. 참고하시기 바랍니다. :)

[@justv1ewer]

[질문] 8:15 삽입할 때 잠그는 것을 삽입 전에 하는 거라고 이해하면 될까요?

[@nullnull_not_eq_null]

네, 맞습니다. 화장실 갈 때를 생각하시면 쉽습니다. 1. 똑똑...(누가 이미 점유했는지 확인) 2. 없으면 진입 + Lock 3. 내가 Unlock하고 나가기 전까지는 모두 줄서서 대기 !!

[@justv1ewer]

@@nullnull_not_eq_null 감사합니다! 최고의 강의!

[@dhk840]

윗글에서 synchronous/asynchronous와 blocking/non-blocking가 개념/구현방법이라 말씀해주셨는데, Boost application performance using asynchronous I/O(2008년에 쓰여진 글이긴 합니다.)에선 개념적으로 보진 않은 것 같습니다. 옛날이랑 지금이랑 변한게 있는걸까요?

[@nullnull_not_eq_null]

음...일단 제 주관적 견해라는 점을 말씀드리고 싶습니다. 개인적으로 동기/비동기라는 것은 처리를 위탁하는 쪽에서 정하는 개념으로 생각하고 있습니다. 성능관점에서 핵심은 결국 스케줄링과 관련이 깊은데 사용자 모드 응용 프로그램은 아무리 잘 스케줄링을 잘 하더라도 운영체제의 통제 범위에서 한정됩니다. 동기/비동기 개념에서 함께 따라다니는 것은 결국 입/출력입니다. 관련 장치에 대한 제어가 따라오는 것은 당연하고요. 그리고 이 모든 것들에 대한 통제는 운영체제 커널에서 이루어집니다. 따라서 커널이 직접 스케줄링 한다면 최적화된 입/출력이 가능하고 결국 좋은 성능으로 이어집니다. 의견 감사합니다. ^^

[@abcduuid]

강의 듣다가 궁금한 점이 생겼는데요 1. 한 쓰레드에서 여러 작업을 동시에 실행하는 것을 비동기 2. 여러 쓰레드에서 여러 작업을 동시에 실행하는 것을 비동기 둘다 비동기라고 볼 수 있나요?

[@nullnull_not_eq_null]

아니오. 동기/비동기와 스레드는 관련이 없습니다. 분리해 생각해야 합니다.

[@wisiasa]

교수님 안녕하세요? db 동기화 관련해서 궁금한 점이 있어 댓글드립니다. 백단 서버 코드를 스프링으로 한다는 가정하에, 그중 DB 부분을 짤 때, 질문1) DBMS 단에서 원래 디폴트 되어있는 아이솔레이션 레벨에 따라 동기화가 잘 동작하기 때문에, 멀티쓰레딩이나 트랜젝션 관리는 따로 할 필요가 없을 것 같은데... 사용 트래픽이 커지면 왜 갑자기 레이스컨디션이 일어나서 이런 작업이 필요하게 되죠? 질문2) 혹시 너무 트래픽이 많아졌을 때, DBMS 자체 아이솔레벨을 너무 높이면 비즈니스로직이 안돌아가고, 그렇다고 그대로두면 레이스컨디션이 발생함으로 '비지니스 로직 코드를' 현재 DBMS의 아이솔레이션 레벨을 고려하며 멀티쓰레딩 및 동기화 해줘야 하는 건가요?

[@nullnull_not_eq_null]

DB자체도 하나의 프로그램입니다. TPS가 증가함에 따라 내부에서 동기화 처리 도중 문제가 발생할 수 있습니다. 물론 철저히 문제를 막기 위한 장치가 있습니다만 아직도 문제가 존재하는 것이 사실입니다. 문제를 해결하는 방법은 여러 가지가 있을 수 있겠습니다. 다만 그것이 정답이 있는 것이 아니라는 점이 개발자를 힘들게 하지요. 애석하게도 제가 이렇게 댓글로 짧게 설명할 수 있는 주제가 아닙니다. 구글링도 해봐야 하고 무엇보다 경험이 필요합니다. 다만 그런 경험을 스스로 해보는 것이 쉽지 않으며 무엇보다 대규모 트래픽을 발생 시키기가 어렵습니다. 이와 관련해 자신의 방법을 찾는다면 학습에도 도움될 뿐 아니라 취업에서도 매우 유리한 경험을 갖게 될 것입니다. 제가 이상민 저자님 책들을 추천한 이유도 이 때문입니다. 꼭 APM에 대해 공부해보시기를 권합니다. 참고하시기 바랍니다. :)

[@landon506]

말씀하신 레이스 컨디션의 문제는 DB layer 보다는 Application Layer 에서의 발생하는 경우를 말씀하시는 것 같은데, 맞을까요? 만약 그렇다면 DB 의 Isolation Level 과는 관련이 없습니다. DB 의 Isolation Level 은 DB 에 저장되는 데이터들의 ACID 를 어떻게 관리할 것인지에 대한 정책이라, 애플리케이션에서 DB 와의 커넥션을 어떻게 맺고 유지 관리할 것인지를 결정하는 일과 무관합니다. 애플리케이션에서 DB 와의 연결성은 보통 Connection Pool 관리를 통해 이루어지는데요 이 Connection Pool 에 Idle 상태로 담겨있는 Connection 을 획득/반납 하는 과정에서 트래픽이 많아질 경우 문제가 될 여지가 있을 수 있다고 여겨집니다. 단, 트래픽이 많다고 무조건 Connection 을 획득하는 과정에서 Race Condition 이 발생한다고 보기는 어렵다고 생각되며 해당 애플리케이션의 특성에 따라 달라질 것으로 보는게 합리적일 것이라 판단됩니다. 즉, 일반화 시키기엔 무리가 있다고 생각하는 견해입니다. 짧은 지식이 도움이 되셨기를 바랍니다..

[@zbflzlxl]

바쁜 대기 말고 이벤트 처리가 더 세련된 방식인 것 같은데, 실제로 저렇게 바쁜 대기가 많이 사용 되나요? 바쁜 대기랑 이벤트 처리 구현의 기징 큰 차이점이 무엇인지 궁금 합니다.

[@nullnull_not_eq_null]

이벤트 처리 체계를 가졌느냐 그렇지 않느냐의 차이로 생각할 수 있겠습니다.

[@wooogy-og]

non-blocking, 동기, 동기화가 혼재되어 설명되어 서… 이들이 전부 이어지는 개념이라고 할 수 있을까요?? 잡힐듯 말듯 하네요. 제 생각에 동기와 동기화는 그 단어 자체와 별개로 의미가 사용되는 컨텍스트가 다르다고 생각이 들었습니다. 동기는 태스크의 실행 순서 또는 I/O와 관련되어 있다면, 동기화는 상태를 맞춰준다 라고 생각이 드는데요. 동기화(synchronized)는 락(Lock)의 방법 중 하나로 동시성 문제(Concurrency issue), 즉 여러 쓰레드가 동일한 자원을 동시에 접근했을 때의 문제점을 해결해주는 것으로써 이야기되기 때문입니다. 어떻게 생각하시는지 궁금합니다.

[@nullnull_not_eq_null]

동기화는 멀티스레드나 멀티 프로세싱할 때 신호등 역할을 해주는 것이고 동기/비동기 I/O는 처리를 요청한 프로세스나 스레드가 응답을 기다릴 것인지 아니면 그냥 다음 코드로 넘어가 제 할 일을 할 것인지를 나누는 것입니다. 결국 모든 입/출력 처리는 OS가 합니다. 참고하시기 바랍니다.

[@wooogy-og]

답변 감사드립니다! 추가 질문이 있습니다. 여기서는 그렇다면 큐가 동일한 자원이 된다는 가정일텐데, 큐는 FIFO 구조임에도 이러한 문제(race condition)를 고려해줘야 하는지 궁금합니다. producer와 consumer 관점에서는 엄밀히 producer는 이벤트를 큐에 넣고, consumer는 해당 이벤트를 빼간다는 다른 영역이라고 생각이 들었는데, 이 부분은 어떻게 생각하시는지 궁금합니다.

[@Blank_____1]

안녕하세요 강의 감사히 잘보고있습니다. 혹시 멀티스레딩 디버깅방법에관해 공유해주실만한 팁같은게있을까요?

[@nullnull_not_eq_null]

음...몇 가지 있는데...윈도우 환경에 특화된 경향이 있습니다. 영상을 하나 더 만들어야 겠네요. ^^ 지금 올렸습니다. 참고하세요. kzbin.info/www/bejne/baHIi5VrbK16nrs

[@모르면전진]

Node JS는 비동기지만 싱글스레드라고 하던데 그럼 이 구조는 굳이 비동기 싱글스레드로 만든게 비효율적이라고 봐도 될까요?

[@nullnull_not_eq_null]

Node.js가 싱글 스레딩이 아니라 JS자체가 싱글 스레딩으로 작동하는 것으로 알고 있습니다. 그리고 비동기라는 것은 다분히 개념적인 것이며 비동기 구조를 적용했을 때 얻을 수 있는 논리적 장점 때문에 사용하다고 생각하시면 되겠습니다. 그리고 오직 효율(혹은 극단적 성능)만 생각한다면 사실 C/C++이나 어셈블리어를 사용해야 합니다. 그렇지 않다면 유지보수성이 뛰어나면서 코드 가독성도 좋고 개발도 편리하고...이런 인간 관점에서의 장점이 더 중요한 시대라 하겠습니다. 결론, 비효율을 말할 이유가 없습니다.

[@dtd6797]

nodejs의 이벤트루프도 머리에 그려지네요! 눈이 트이는 느낌 너무 좋아요. 독하게 c언어 책의 예제를 따라쳐본게 도움이 엄청많이 되네요!

[@nullnull_not_eq_null]

아하~~! 그렇군요. 이해를 얻으신 것 같아 강사로써 기쁩니다. ^^

[@ilililililiilllililli]

webflux 나 리액티브자바가 컨텍스트스위칭이 걸리지 않고 비동기 작업을 빠르게하는 동작원리 설명좀 부탁드리겠습니다 ㅠ

[@nullnull_not_eq_null]

제가 잘 아는 분야는 아니라서 정확히 말씀드리기는 어려워 당장 답변을 드릴 수는 없겠습니다. 저도 공부를 좀 해보고 답변 올리겠습니다. 감사합니다. ^^

[@richardkang1983]

어디가 비동기라는 걸까? 파일읽기? 소켓에 쓰기? 굳이 쓰레드로 역할을 구분했음에도.

[@nullnull_not_eq_null]

의견 고맙습니다.

[@seung-kyojin8296]

너무 재미있습니다...! 최고입니다~

[@nullnull_not_eq_null]

좋은 평가와 피드백 감사합니다. 최근에 운영체제와 시스템 프로그래밍 강의를 올리고 있습니다. 함께 보시면 더 도움이 될 것으로 보입니다. 참고하세요. ^^

[@qkrtmddn0507]

저만 알고 싶은 명강의입니다 ㅎㅎㅎㅎ

[@nullnull_not_eq_null]

좋은 평가 감사합니다. 그리고 채널이 성장하지 못하면 제가 채널을 닫을 지도 모르니...널리 알려주세요. 저도 그 실버버튼을 꼭 갖고 싶어서요 ^0^;;;

[@hyeopkim5928]

한 url에서 예시의 작업(request: 영상 파일 읽기-> 처리-> 응답)을 하도록 api를 작성했다고 했을 때, 비동기를 지원하는 api로 작성했다면 알아서 쓰레드를 나눠서 작업하나요? 아니라면 쓰레드를 나누는 작업은 누가 해주는 건가요? (강의 너무 재밌습니다bb)

[@nullnull_not_eq_null]

스레드를 나누는 작업은 개발자 자신이 해야 합니다. 만일 영상파일 처리 시간이 많이 걸리는 대용량 파일들이라면 응답을 분리하는 것도 한 방법이 되긴 하겠습니다. 그리고 피드백 감사합니다. ^^

[@CatabraAbra]

고맙습니다😘

[@nullnull_not_eq_null]

저도 고맙습니다. ^^

[@yrrho0190]

감사합니다

[@nullnull_not_eq_null]

응원 감사합니다. ^^

[@ConstantSTAN]

강의를 듣다 보면 운영체제에 적용된 개념들이 프레임워크나 라이브러리, 도커와 같은 컨테이너 기술 등에도 거의 유사한 개념들이 적용되어 있다는 것이 조금씩 느껴져 참 흥미롭고 신기합니다~ 좀 더 프로그래밍의 근간이 되는 지식과 기술들을 학습해봐야 겠습니다

[@nullnull_not_eq_null]

음...기본 원리는 같습니다. 거기서 파생 발전되는 형태로 이해하시면 되겠습니다. 필요한 것이 있다면 언제든 설명을 요청하시기 바랍니다. 제가 알고 있는 것에 대해서는 영상으로 답변을 드리겠습니다.

[@delta4489]

오,,첫번째

[@nullnull_not_eq_null]

1위 경쟁이 치열하네요.^^;;;

[@ryanlee5435]

까비..

[@swb5272]

감사합니다.

[@swb5272]

좋은 강의 감사합니다!!

[@swb5272]

스레드는 작업 단위(작업자)를 얼마나 둘 것인지에 대한 문제 - 프로세스의 동영상 처리에 몇개의 작업자(스레드)를 둘 것인가? - 동영상 다운로드 1, 동영상 재생 1, 동영상 업로드(송신) 1 - 각 작업은 순차적으로 이루어져야 하고, 3개의 스레드가 나눠서 처리한다. - 멀티스레드 and blocking i/o의 방식이라면 - 동영상 600mb를 모두 다운로드 받은 뒤에 동영상을 재생하고, 동영상 재생이 모두 완료되면 동영상을 업로드한다. - 멀티스레드 and non blocking i/o의 방식이라면 - 다운로드 스레드에서 동영상이 1mb(최소 단위) 다운로드되면 일단 재생 스레드가 재생시키고 재생이 완료된 분만큼 동영상 업로드 스레드가 업로드한다. - 다음 분량의 동영상이 다운로드되는대로 이를 반복하며 각 스레드가 계속 일을 한다. - 동영상이 모두 다운로드되면 얼마 안있어 동영상 업로드 또한 완료될 것이다. 비동기 I/O는 각 스레드(single or multi)에서 작업을 어떻게 실행하고 처리할 것인가에 대한 문제, 멀티 스레드는 스레드(작업자)를 얼마나, 어떻게 배치할 것인가에 대한 문제. 서로 바라보는 관점이 다르다 (task / executor)

[@swb5272]

동영상 보고 이 정도로 이해했는데.. 혹시 맞지 않는 내용 있을까요?

[@nullnull_not_eq_null]

와우~~! 후원 감사합니다. 몽땅 커피마시는데 사용하겠습니다. ^^

[@nullnull_not_eq_null]

개념적인 내용입니다. 일단 이 정도로 알고 계셔도 무방하겠습니다. 개념적인 측면에서 한 가지 더 알아 두기를 바라는 것은 'OS도 프로그램'이라는 사실입니다. 동기/비동기 라는 것도 따지고 보면 별것 아닙니다. I/O를 통제하는 역할을 수행중인 OS에게 I/O 꺼리를 던져주고 기다릴 것인지 아니면 잊고 있다가 전화를 받을 것인지...그 차이 정도가 되겠습니다. 'OS도 프로그램'이라는 사실을 꼭 기억해두시기 바랍니다. 조금 다르긴 하지만 이 관점에서 Docker 기술이나 가상화 기술도 이해할 수 있습니다. Word를 여러 개 실행해 여러 문서를 보는 것과 비슷합니다.