thread 프로그램을 해야하는 이유.

-- 멀티스레드를 사용하는 이유

1) 멀티프로세스 보다 훨씬 좋을 때

당연한 얘기로 웹서버를 보면 알 수 있습니다.

2) CPU 가 여러 개일 경우를 대비하여
3) CPU 가 노는 시간을 최대한 없에려고

파일입출력 시나 주변장치 입출력 시에
보통 체널이나 DMA 가 관여하지 CPU 는 잘 관여하지 않습니다.
이런 상태의 CPU 를 다른 작업에 사용한다면 더 효율적일 것입니다.

5) 최종 사용자 인터페이스와 관련하여

용량이 큰 하드가 달린 컴에서 윈도우 탐색기를 실행하면
일단 주스레드는 최상위 디렉토리 정보만 보여주고
다른 스레드가 그 외 디렉토리 정보를 메모리에 꼐속 쌓고 있을 것입니다.
이런 때처럼 사용자 인터페이스와 관련해서 멀티스레드를 사용하는 경우가 있습니다.

To chunsj English Mania:

In short, DO USE THREAD IF IT REALLY NEEDS.
AND Speak IN Korean

저는 이 말에 매우 공감합니다 :)

이 말을 사용한 의도는 fork 대신 thread를 사용하려고 할 때 정말로 필요할 때만 thread를 사용하라고 하는 것인 듯 합니다.

실제로 fork가 thread보다 조금 무겁다는 것 이외에 디버깅 측면에서 보나 안정성 측면에서 보나 fork가 프로그래밍하기 훨씬 편하죠 ^^;;

scalable을 생각했다 하더라도 어차피 task의 숫자가 무지하게 늘어나면 한 task를 만들 때 overhead보다는 수많은 task를 스케줄하는 overhead가 훨씬 크기 때문에 생각보다 thread가 fork보다 월등히 앞서지도 않습니다.

정말로 scalable을 생각했다면 non-blocking IO + select/poll/kqueue/epoll 등을 생각해야겠죠.

물론 정말로 thread가 필요할 때는 task간에 공유하는 것도 많고 같이 처리하는 것도 많아서 밀접한 관계에 있을 때라고 할 수 있을 것 같습니다.

스레드를 사용하면 다음의 두 가지 장점이 있습니다.

1. 평균 처리 시간이 짧아진다.
예를 들어 A라는 task가 10이라는 시간이 걸리고 B라는 task가 1이라는 시간이 걸린다고 가정합시다.

1) single thread로 처리할 경우
A를 먼저 처리하고 B를 처리한다고 하면, A는 처리에 10이라는 시간이 들고 B는 처리에 11이라는 시간이 든다. 평균 처리 시간은 10.5
2) multi thread로 처리할 경우
A를 먼저 처리하고 B를 처리한다고 가정하고, time slice를 1씩 고르게 배분한다고 가정하면, A를 처리하는데 11이라는 시간이 들고 B를 처리하는데 2라는 시간이 든다. 평균 처리 시간은 6.5

context switch cost를 고려하지 않았을 때, 총 처리시간은 11로 같지만 A,B를 처리하는데 평균적으로 걸린 시간은 multi thread 기반일 때가 빠르다는 것을 알 수 있습니다. 여기서 주의해서 보실 것은 스케쥴링이 잘 될 경우 sigle thread 기반이 더 빠르다는 것입니다. B를 먼저 처리하고 A를 처리한다면 평균 처리 시간이 6이 되고 더욱이 context switch cost도 없게 되지요. 하지만 이는 스케쥴을 잘 해줘야 하는 cost가 들기 때문에

'일반적'으로 multi thread 기반의 프로그래밍이 평균 처리 속도를 빠르게 할 수 있다. 는 것을 알 수 있습니다.

2. I/O operation이 많을 때 노는 CPU를 사용할 수 있다.
이는 다들 아실 내용일 것 같아 생략하겠습니다. ^^

multi thread기반 프로그래밍은 goto와 유사한 이유로 해로울 수 있습니다. 프로그램의 어떤 한 시점에서의 의미가 명확해지지 않기 때문인데요.. 유명한 goto statement considered harmful 이라는 논문을 읽어보시면 좀 더 자세한 설명을 보실 수 있습니다.

http://www.acm.org/classics/oct95/

하지만 평균 반응 시간이라던가 I/O가 많은 프로그램에서의 장점은 무시할 수 없기 때문에 꼭 필요할 때는 써 줘야 겠지요.. :)

움.. 분명 여러개의 하드웨어를 제어하기 위해서 사용한다고

명시되어 있는데요. 그리고, 답글의 분위기가 조금 읽기 편하지가 않습니다.

단어나 글의 끝이 부드러운 글이면 좋겠습니다.

그럼..

"저글의 답변은 이미 질문자체에 써놓았네요.. 질문올릴필요가 없는" 거라면
그런 질문에 대한 답글을 남길 필요까지도 없었던 거죠
따라서 그냥 보고 지나쳤어야 했겠죠
굳이 답글을 왜 달았죠

저도 이런 경우를 많이 겪는데..

전 일단 fork 씁니다.

스레드도 사용해 보았으나.. 요즘 메모리야 남아도는데..128M 써도 영상 쪽

아니면 꽉 차는 경우는 드물던데요.

스레드를 사용하지 않는 이유는 일단 예기치 못한 오류가 많이 났던거 같던데요.

오래되서기억은안나지만 하나의 프로세스를 둘이상의 스레드로 나누고

그중 한 스레드를 또다시 스레딩 하면 (말이 좀 이상한가요-_-)..

얘기치 못한 상황이 많이 나더군요..

환경은 리눅스 였습니다.

fork 는 아무리 쪼개도 -_- 이상없더군요.

또한 성능면에서도 별 차이 못느꼈구요..

그래서 전 요즘도 fork 한번쓰고 빼먹고 코딩안한거 있음.. 다시 뒤엎기 귀찮아서

포크앞에 스레드 넣어줍니다. ㅋㅋ

또한 포크는 관련함수가 작잖아요 ㅋ

아참 메모리 공유땜에 스레드를 써야할때도 전 그냥 공유메모리를써는 편입니다.

머리가 나빠서.. 스레드 동기 맞추는게 싫더라구요 -_- :wink:

이상 허접답변이었습니다.

이 곳의 주제를 Linux에 (또는 unix?) 제한하고 있지는 않지만, 주류는 그 분야라고 생각하고 있었는데, 의외로 fork는 모르고 thread는 아는 사람이 많이 있네요.

물론 win32쪽을 먼저 접하면 충분히 있을 수 있는 일입니다만, 신기하네요 :)
나쁘다는 것은 아닙니다 ^^;;

fork대신 thread를 쓰는 대부분의 경우는 process의 개수를 줄이기 위해서가 아닐까요.

물론 process의 배치를 어떻게 하느냐에 따라 달라지지만 일반적으로 fork를 하여서 비즈니스 로직을 처리하는 경우 작업 요청자의 숫자만큼 process가 생기기 때문에 performance에 영향을 줄 수 있기 때문에 thread를 사용하는 것 같습니다.

아마 fork 천 개만 해도 context switch하는 것이 눈에 보일 것입니다.

그러므로 프로그램의 구조상 어쩔 수 없이 fork하여 작업을 처리하는 형태를 thread를 사용함으로써 thrashing을 막자는 것이 아닐까요..

다른 분들이 많이 말씀해 주셨지만 저도 몇가지 말해 봅니다
thread 가 fork 보다 선호되는 이유는

일단 스레드간 통신이 훨씬 쉽습니다.
fork 는 IPC 등 으로 통신해야 하는데 반해
thread 는 전역 변수가 공유 됩니다.

그리고 fork 는 프로세스에서 text 영역을 뺀 나머지를
그대로 복사해서 수행하지만 thread 는 필요 요소만 복사해서
수행되기 때문에 메모리도 조금 차지 합니다. 또 이러한 이유로
생성도 더 빠르다고 합니다