왜 다들 멀티쓰레드인가?

sia79의 이미지

SI경력뿐이 없는 아직 초짜입니다. C on linux
여태 파견을 나간 곳에서는 전부 멀티 쓰레드를 이용해서 구현하라고 합니다.
컴퓨터를 제대로 배우지 않은 제게 쓰레드 프로그래밍은 정말 끔찍하더군요.
백몇대의 기계를 제어하는 것인데, 정해진 규약대로 DB살피면서 기계스케쥴을 만들고,
0과 1만 날려주고 받고 처리하고 합니다.
한번은 제가 의견을 피력할 기회가 있어서... ( 솔직히 쓰레드프로그램 디버깅이 너무 어려워서. )
큰 기능별로 프로그램 서너개로 만들어서 운영해보는 것은 어떠냐고 했습니다.
우스개소리로 system()함수로 인자넘겨서 실행하기도 하자고 했는데,
다들 저를 보고 여태 뭐했냐 식으로 깔보는 것같더군요. 뭐, 제가 전산 지식이 얕은 것은 사실이지만;
10이면 9이 모두 쓰레드 프로그래밍을 해야만한다고 생각하고 있고,
아니, 쓰레드프로그래밍이 아니면 프로그램도 아니라는 생각을 하고 있는 듯합니다;;;
왜냐고 물어보면 자원 절약, 리스크, 속도면에서 월등하다고 합니다만 솔직히 잘 모르겠습니다.
이번, 제가 일하는 곳이 임배디드 개발도 아니고, 그냥 오픈계 어플리케이션입니다.
fork(), IPC도 필요하니까 있는 것아니겠습니까;;;

제 지식이 낮으면서도 포럼에 이런 글을 쓰는 것이 조금 걱정이긴 하지만,
멀티 쓰레드 진정 어떤 때 필요한 것인지, 어떻게 검증을 해야하는지 이야기 해 보고 싶어서 글을 남깁니다.;

나는오리의 이미지

저와는 반대네요.
전 각 분류별로 나눠서 프로그램을 만들자고 윗사람들과 싸워서 이겼지요.
디버깅도 짜증나고
오류나면 찾기가 까다롭고
쓰레드 하나 죽으면 대책없지만
각각의 프로그램으로 만들어두면 프로그램 하나만 죽였다 살리면 되거든요.
그리고 각 프로그램을 관리하는 프로그램 하나 띄워놓고 거기서 컨트롤 다해요.

잡설은 그만하고 본론을 이야기하자면

fork,ipc도 필요하니까 있는것인만큼
쓰레드도 필요하니까 있는것이겠지요.
다른 사람들이 쓰레드를 고집하는 이유부터 확인하고
그에 대해 쓰레드를 프로그램로 만들었을경우 얻을수 있는 장점과 단점을들 보고서로 만들어
왜 프로그램로 만들어야 하는지를 보고하면 다른 사람들도 수긍할 것입니다.

--- 초보오리

sia79의 이미지

써주신 것 그대로가 제 생각이고, 그대로 말씀 드렸지요. 디버깅 부분을 좀 강조하면서...

가볍다, 즉시 대응이 빠르다, 컴퓨터 자원을 적게 쓴다. 추상적인 말만 듣다가 결국,

위쪽 지시랍니다; ? 우리 위가 어딘지도 잘 모르겠고;;;

최소한 지금 여기 현장에서는 멀티 프로세스가 멀티 쓰레드를 충분히 대신할 수 있다고 생각하는데.

기계제어하는 컴퓨터도 서버급으로 성능이 좋거든요.

쉬프트 타임으로 일하기때문에 글을 끄적여봤습니다;

공장 일 끝나는 시간이 저는 일 시작. ㅜ.ㅜ

이제 좀 자야겠네요.

dhunter의 이미지

어떤 운영체제 기반인지는 모르겠지만 WIN32에서 쓰레드는 사실상 전통에 가깝고, 쓰레드 처리가 멀티 프로세스 처리보다 나은편이거든요.

그쪽으로 배운 사람들은 그게 편할겁니다.

요즘은 Linux에서도 쓰레드 사용이 늘어나는 추세니 글 쓴 분이 공부하시는게 낫지 않을까요.
--
from bzImage
It's blue paper

from bzImage
It's blue paper

sia79의 이미지

그... 그렇군요.

멀티 쓰레드나 멀티 프로세스나 별 차이 없다고 느껴지는 것을 보면 분명 공부가 아주 많이 필요하긴 합니다;

그런데, 쓰레드쪽 공부하기가 어려운게 문서들이 보통 거의 영어라서요;;;

국내서로 몇몇 책을 사서 보고 있지만, 쓰레드에 관해서는 100페이지 미만이더군요;

서너권의 네트워크 프로그래밍과 함께 설명되어 있는 것이 전부였습니다. 아마 기초적인 내용이겠죠.

혹시, 국내서 (번역서도 상관없습니다.)중 추천해주실만한 책이 있다면 알려주십시요.

feanor의 이미지

개인적인 의견으로는, 서로 다른 쓰레드 사이에 주고받아야 하는 데이터가 많아서 멀티 프로세스로 갔을 때 serialization 오버헤드가 크지 않다면 멀티 프로세스로 가는 편이 낫다고 생각합니다.

Serialization 오버헤드를 뺀다면, 유닉스 환경에서, 자원이나 성능 문제는 큰 차이가 없을 것으로 생각되고, 프로세스는 죽이고 다시 시작할 수 있으니까 안정성 면에서는 멀티 쓰레드보다 오히려 낫다고 봅니다.

jick의 이미지

(뭐 외국에선 되는지 잘 모르겠습니다만) 원칙적으로는 누가 "쓰레드가 더 좋다!"라고 주장하고 싶으면 쓰레드가 왜 좋은지 정량적 근거를 들고 와서 얘기해야 하는데,

우리나라에선 윗선에서 "쓰레드가 좋아!" 하면 아랫선에서 근거 제시를 요구하기는커녕 쓰레드가 더 나쁜 케이스를 찾아서 근거를 들고와도 반론이 될까말까하죠. (뭐 반대로 윗선에서 "쓰레드는 무조건 안돼!" 할 경우도 마찬가지고.)

수십 명이 몇 년씩 달라붙어 개발하는 초대형 프로젝트의 기반 아키텍쳐가 경영진의 편견 내지는 영업포인트에 의해 "쓰레드를 써야 '쓰레드를 썼으니 성능이 빠르다!'라고 광고할 수 있어, 그러니 쓰레드 기반으로 가자!" 이런 식으로 결정되는 모습을 겪으니 참 답답하더군요. 그렇다고 수십년 연상의 회사 창립자한테 "니가 쓰레드가 더 빠른지 짜서 재봤어?" 할 수도 없는 노릇이고...... -.-;;;

어쩌면 인류 공통적인 현상일까요... -.-

아르아의 이미지

멀티쓰레드로도 짤 수있고,
멀티프로세스로도 짤 수 있고,
더 좋은 다른 방법도 있을 수 있을겁니다.
하지만 할줄아는게 A밖에 없어서 A로 하는것과
A,B,C다 잘하는데 지금경우 A가 가장 좋아서 A로 하는것은 다르죠.

그리고 A가 가장좋더라도
사람들이 B에 가장 능숙하다면
B로 하는것이(적어도 단기적으로는) 더 좋겠죠.
A로 짜느라 1000시간 걸릴것을
익숙한 B로 100시간에 짜고 900시간동안 프로그램 품질을 올리면 되니까요.

따라서, 특히 회사에서는
기술적으로 가장 바람직한 방법과
최선의 방법은 항상 같지는 않은듯 합니다.
같도록 하는것이 최선일테니, 그렇게 되도록 노력해야겠지요

zelon의 이미지

오랜 시간이 걸리는 I/O 나, 응답성을 빠르게해야하는 부분이 아닌 곳은 쓰레드를 안 쓰는 게 정석일 듯 합니다.

앞의 분도 말씀하셨지만 디버깅이 힘듭니다. 유지보수에 드는 비용이 대두되는 요즘에는 특히 쓰레드를 꼭 써야하는 곳이 아닌 다음에는 안 쓰는게 좋을 듯 합니다.

반대로 말씀드리면 I/O 관련하거나, 빠른 응답성을 요구한다면(다른 일을 할 때도 interaction 이 잘되게 하려면) 당연히(!) 쓰레드를 써야합니다.

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
http://www.wimy.com

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

winner의 이미지

Thread 단위로 보호하고, 관리할 방법은 없나요?

http://kldp.org/node/95172

cbangsae의 이미지

cbangsae

bookgekgom의 이미지

멀티쓰레드를 써야마느냐는 절대적인게 아니라 자신이 무엇을 짜는지에 따라 바뀌는거 아닌가요

윗분들 말들중에 주옥같은 말이 많으니 천천히 읽어 보시기를 바랍니다.

그리고 멀티프로세싱이 멀티스레딩을 대신할수있다?

그야 당연히 배추써는 칼로도 복어회를 뜰수있겠지요.

ㅋㅋㅋㅋㅋ

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

오호라의 이미지

thread 는 곧 lock 입니다.

정말 잘 만들어진 쓰레드구조 아니라면 대부분의 시간을 락을 잡을려고 대기하다 시간 다 보내는 것을 알수 있을겁니다.

그러나, 통신이란 특성상 쓰레드는 불가침한 면도 있는 듯합니다.

Hello World.

hongja의 이미지

쓸려면 그거 써서 개발해라고 할텐데,
분명히 필요해서 그렇게 말한듯 합니다.
리눅스를 몰라, 답을 달순없지만 윈도우개발자 입장에서봐도 댓글들중에 이해가 갈만한 글이 없어서...
몇자적어둡니다.
UI로 이해하면 빠른데, 사용자가 능동적으로 처리하는 UI 부분과 내부적으로 무한처리되는프로세스 부분이 멀티쓰레드가 구현하지 않으면 한처리가 끝날동안 다른 처리를 할 수가 없습니다. 즉 UI먹통상태가 발생할 수 있는것이죠.
내부 무한프로세스가 통신을 담당한다면, 원하는 데이타가 넘어왔을때 메세지나 이벤트로 UI에 노출하고 자기 쓰레드 프로세스는 계속 다음 응답상태로 넘어가는 거죠.
외부 프로그램을 여러개 만들어 돌린다면, 외부 프로그램간에 마샬링을 통한 인터페이스로 참조주소나 데이타 교환이 개발에서 난점에 부딪힐 경우가 매우 많습니다. 비관리기반에 안정성도 떨어지겠죠.
각각의 프로그램간에 연관성이 없이 독립적인 역할을 한다면 무방합니다.