이상준 님이 쓰신 글 :
: 안녕하세요
: 쓰레드의 블로킹과 논블로킹을 알려주세요

thread에 blocking 과 nonblocking이 있는 게 아닙니다.

func1();
func2();
func3();

소스코드가 위와 같을 때,

func1이 blocking이라면 func1이 실행종료(return)되어야 비로소 func2가 실행될 수 있음.

func1이 nonblocking이라면 func1이 실행되고 있는 상태에서 func2가 실행될 수 있음.

func2가 blocking이라면 func2가 실행종료(return)되어야 비로소 func3가 실행될 수 있음.

func2가 nonblocking이라면 func2가 실행되고 있는 상태에서 func3가 실행될 수 있음.

함수로 설명한 것은 이해를 쉽게 하기 위한 것입니다.
CreateThread WinAPI 함수의 매개변수인 lpStartAddress에 지정하는 함수는 그 자체가 thread라고 할 수도 있으므로 제외하고,
어떤 식이든 해당 함수가 return되어야 다음 함수가 실행된다는 점을 생각하면 엄밀한 의미에서 함수가 nonblocking일 수는 없습니다. 다른 대상을 nonblocking으로 만들기 위한 함수는 있겠으나...

굳이 thread에 대해 이를 적용해보면,  thread 자체는 기본적으로 nonblocking이라고 보면 될것입니다.
즉, thread1,thread2,thread3를 순서대로 실행시킨다고 할 때 앞의 것이 실행종료되어야 뒤의 것이 실행되는 것이 아니고 thread1,thread2,thread3이 동시에 실행상태에 있다는 것이죠.
thread로 나누지 않은 상태에서 nonblocking은 event 기반으로 나타납니다.

우리가 보통 생각하기에는 blocking이 일반적이고 자연스럽습니다.
blocking이라는 것은 순서대로 실행하여 현재 것이 완전히 종료되면 다음 것을 실행하는 것이니까요.
nonblocking이 가능한 것은 운영체제가 프로세스,스레드를 실행할 때 앞의 것을 완전하게 실행하여 끝낸 후 다음 것을 실행하는 것이 아니라 앞의 것을 어느정도 실행한 후 다음 것을 실행할 수 있기 때문입니다.
시분할 방식으로 하게 됩니다.

M$ Windows에서 event 기반으로 작성된 프로세스, 스레드라고 하더라도 각 프로세스, 스레드는 전체적으로 보면 결국 blocking입니다.
즉, 현재 처리중인 event의 핸들러가 실행종료되어야 다음 event를 처리하는 형식이므로...
물론, event  핸들러 내에서 다시 ProcessMessages 등의 함수를 호출하여 다음 event를 처리할 수 있지만 이 역시 ProcessMessages를 내부에서 호출하여 한 것이으므로 blocking임.

운영체제는 thread context를 관리합니다.

Socket에서 blocking,nonblocking이 있는데 이는 다음과 같습니다.
여기서 소켓은 통신 시 양단간에 연결하여 데이터를 주고받기 위한 것입니다.
nonblocking:
응용프로그램은 "저쪽에서 메시지 오면 알려줘!"라고 운영체제에게 말합니다.
그리고는 다른 할 일을 합니다.
그러다가, 운영체제가 "메시지 왔어!"라고 하면 응용프로램은 해당 메시지에 상응한 일을 합니다.
물론, 다른 하던 일을 마무리한 다음 합니다.
상응한 일을 끝내면 또 다른 할 일을 합니다.

blocking :
응용프로그램은 "저쪽에서 메시지 오면 알려줘!"라고 운영체제에게 말하지 않습니다.
그러니까, 매달려 있어야 합니다. 즉, blocking되는 것입니다.

이 blocking socket을 nonblocking처럼 만들려면 별도의 스레드에서 작업하면 됩니다.
스레드는 기본적으로 nonblocking이므로 그 안에서 하는 작업도 결국 nonblocking이 되는 것입니다.

위에서 block은 자신이 block된다는 의미가 아니고 다른 것을 block한다는 의미입니다.
예를 들어, func1이 blocking이라면 func1은 func2를 block한다는 의미입니다.