Recent Comments 가져오기

기술이 중요한게 아닌듯

구글 OS는 티맥스 윈도우 기술력의 1/5도 안된다고말했던가 ? 중요한건 기술이 아닌 것 같다. disqus를 보면 그런생각이 든다. 개인적으로 이러한 댓글 시스템을 원했기 때문에 유독 반갑게 받아들이긴 했지만 말이다.

disqus는 소셜댓글 시스템을 표방한다. 사이트와 서비스에 관계없이 붙여 놓으면 서로 커뮤니케이션이 가능하며, 자신의 댓글을 쉽게 관리할 수 있도록 도와준다. 여기 저기 사이트 돌아다니면서 댓글 달아 놓은게 얼마던가. 그러나 그렇게 하면 뭐하나. 며칠 지나면 자주방문하는 사이트의 댓글이 아닌 한은 몽땅 잃어버리고 만다. 댓글이라는 것이 서로간의 커뮤니케이션을 위한 도구라고 하는데, 써놓고 잃어 버린다면 이게 무슨 소용인가. 소통을 위한 시스템인데, 막상 소통의 접점을 잃어버리게 되고 만다. 그렇다고 댓글 써놓은 사이트와 포스트를 일일이 관리할 수도 없는 일이고.

disqus는 공통의 저장소에 댓글을 저장하며, 저장된 댓글은 open api 를 이용해서 access 가능하도록 하고 있다. 이렇게 함으로써 사이트에 관계없이 댓글을 사용할 수 있도록 하고 있다. 댓글이 공통의 저장소에 관리되므로 댓글관리도 물론 편하다. 간단하게 자신의 댓글과 그 댓글에 댓글까지를 한꺼번에 관리할 수 있다. 거기에 자신의 email로 댓글들이 배달되니 여하튼 이처럼 편할 수 없다.

disqus 시스템이 나의 적성에 맞는 또다른 이유는 이것 저것 가져다가 붙이는 걸 좋아하는 내 성격에 맞기 때문이다. 어떤 차이에서 인지는 모르겠지만 영미권 얘들의 사이트를 보면 이것저것 공개된 툴들을 가져다 붙이는 형식을 선호하는 것 같다. 반대로 우리나라의 사이트는 하나로 끝나는 통패키지를 선호하는 것 같다.

가상 게시판

예컨데 가상 게시판같은 거라고 보면 될 거 같다. 예전에 가상 게시판같 은걸 생각한적이 있었다. 마음대로 게시판을 생성할 수 있고, 또한 그 게시판들끼리 게시내용들이 공유되는 그런 시스템이였다. 실제 나는 참가하지 않았지만 그러한 프로젝트도 진행되었었다. 그런데 완성되지 못하고 disqus는 완성이 되었다. 어디에서 그 차이가 나는 걸까. disqus와 예전의 그 프로젝트를 보면, 얼마나 많은 기술이 들어갔는지 아키텍쳐는 얼마나 훌륭한지가 중요한게 아닌 것 같다란 생각이 든다.

고객이 원하는게 아닌 내가 원하는게 무엇인지를 알고 그걸 만들기 위해 노력하는것 그게 결정적인 차이인 것 같다. 그때 그 프로젝트가 실패한 이유는 사용자가 원하는 걸 만들려고 했기 때문이 아닐까. ?

개인적인 생각인데, disqus에서 제공하는 open api 를 이용하면 댓글시스템을 넘어서서 가상게시판도 만들수 있을 것 같다. disqus api를 분석해서 만들어볼 요량이다.

joinc에 붙이기

현재 joinc 위키 페이지와 개인 블로그에 disqus를 붙였다. 그리고 개인적으로 만들고 있는 영문 맨페이지에도 disqus를 붙였다.

미디어를 장악하려는 이유

논어ISBN : 9788970650340를 읽고..

서점에 가면 프로젝트 관리와 관련된 책들이 널려있다. 특히 애자일 열풍?이 불어닥치면서 애자일 관련된 책들만해도 수십권은 되어보인다. 그런책들은 언제 시간나면 한번 읽어보기로 하고, 논어에 나오는 격언들을 프로젝트관리에 적용시켜보면 어떨까라는 생각이 느닷없이 든김에 생각을 정리해 보기로 했다.

공자왈 백성들을 정치로 인도하고 형벌로 다스리면 백성들은 형벌을 면하고도 부끄러워함이 없다. 그러나 덕으로 인도하고 예로써 다스리면, 백성들은 부끄러워할 줄도 알고 또한 잘못을 바로잡게 된다.
공자왈 군자는 천하에서, 반드시 그래야만 한다는 것도 없고, 절대로 안된다는 것도 없으며, 오직 의로움만을 따를 뿐이다
공자왈 군자는 말에 대해서는 모자라는 듯이 하려하고, 행동에 대해서는 민첩하려고 한다
자유왈 임금을 섬김에 번거롭게 자주 간언을 하면 곤욕을 치루고 치욕을 당하게 되고, 친구에게 번거롭게 자주 충고하면 곧 소원해진다.
공자왈 군자는 절박한 것은 도와주지만 부유한자가 더 부자가 되게 도와주지 않는다
자로가 여쭈었다. 선생님께서 삼군을 통솔하신다면 누구와 함께 하시겠습니까 ? 공자께서 말씀하시길 맨손으로 범을 잡고 맨몸으로 황하를 건너려다 죽어도 후회가 없는 사람과는, 나는 함께하지 않겠다. 반드시 일을 대담에 신중하게 하고, 계획을 잘 세워 일을 이루는 사람과 함께 하겠다.
공자왈 부가 만약 추구해서 얻을 수 있는 것이라면, 비록 채찍을 드는 천한 일이라도 하는 하겠다. 그러나 추구해서 얻을 수 없는 것이라면 내가 좋아하는 일을 하겠다
군자는 평온하고 너그럽지만, 소인은 늘 근심에 쌓여있다.
마굿간에 불이 났었는데, 공자께서 퇴근하시어 사람이 다쳤느냐라고 물으시고는 말에 대해서는 묻지 않으셨다.
공자께서 말씀하셨다. 지나친 것은 모자란 것과 마찬가지이네

중궁이 정치에 대해 여쭙다. 공자께서 말씀하시길 먼저 실무자들에게 일을 분담시키고, 작은 잘못은 용서해 주며, 현명한 인재를 등용하거라
섭공이 정치에 대해서 묻자, 공자님께서 말씀하시길 가까이 있는 사람들은 기뻐하고, 먼 데 있는 사람들은 찾아오도록 하는 것입니다라고 하셨다.
자하가 정치에 대해 여쭙자, 공자께서 말씀하시길 빨리 성과를 보려 하지 말고, 작은 이익을 추구하지 말라. 빨리 성과를 보려하면 제대로 성과를 달성하지 못하고, 작은 이익을 추구하면 큰일이 이루어지지 않는다
공자께서 말씀하셨다. 가난하면서 원망하지 않기는 어렵지만, 부자 이면서 교만하지 않기는 쉽다
공자께서는 네 가지를 절대로 하지 않으셨다. 사사로운 뜻을 갖는일이 없으셨고, 기필코 해야 한다는 일이 없으셨으며, 무리하게 고집부리는 일도 없으셨고, 자신만을 내세우려는 일도 없으셨다.
현대 자본주의 사회에서 살아남기 위한 덕목은 스피드와 경쟁력, 효율성이다. 이를 달성하기 위해서 시간과 공간을 집적시키길 원한다. 때로 인간다운 삶을 포기해야 한다. 이러한 현실에 비추어 유교의 가르침은 고리타분하고 비현실적이라는 느낌을 줄 수 있다. 욕심 없이 유유자적하면서 살 것이라면 모르지만 치열한 경쟁 사회에서 살아가기위한 지침으로 삼기엔 적당하지 않다고 생각되어지기 때문이다. 아름답지만 현실적이지 않은 가르침이라고나 할까 ?

시간과 공간을 집적시켜서 효율을 극대화 시키고 그것으로 이윤을 창출했던 산업시대에는 확실히 유교의 느긋함, 길게 보기, 사람 중심으로 보기, 결과 보다는 과정이 런건 사치로 여겨졌을 지도 모르겠다. 정보화,인터넷 시대인 지금 이러한 인식이 변하고 있다. 소프트웨어 업계의 여러가지 새로운 개방방법론들은 산업시대의 것들과는 분명히 다르며, 동양적사상을 오히려 따르려 하고 있음을 느낄 수 있다.

공자님의 격언을 보면 일관되게 일을 함에 있어서 소소한 것에 크게 신경쓰지 말라라고 하신다. 그게 해야할 업무이건 실수이건 간에 말이다. 큰것을 해결하면, 작은 것은 알아서 해결되는 경우가 많기 때문이다. 작은 것들에 신경을 쓰는 가장 흔한 이유는 잠깐이면 끝낼 수 있는 것 아니냐. 내가하면 5분안에 끝낼 수 있는데..라는 생각 때문인 것 같다. 큰일을 해결하면 작은일들도 해결되지만 작은일들이 모이면 큰일이 된다. 네버엔딩 프로젝트가 될 수도 있다. 인내와 믿음이 있어야 가능한 일이다.

음.. 완성된 문서가 아닙니다. 문서는 wiki 를 통해서 계속 수정/보완해나갈 생각입니다.

1 Linux More Popular as Deployment Platform

많은 개발자들이 자신의 실력을 다른 개발자들에게 자랑하기 위해서 혹은 그들과 의견을 주고 받기 위한 목적으로 오픈소스 프로젝트를 수행한다. 많은 경우 프로젝트 리더들은 프로젝트를 함께 개발하는 개발자의 소프트웨어 개발 환경에 대한 정보를 알기를 원한다.

이클립스 프로젝트는 4월 일반적인 개발자들이 어떠한 환경에서 개발을 하는지에 대한 광범위한 조사를 실시 했다. 주목할만한 내용은 개발플렛폼으로 리눅스가 상당한 진보를 이루어냈으며, 특히 배포플랫폼으로써는 윈도우즈를 추월했다는 점이 될 것이다.

이클립스 제단의 마케팅 디렉터인 Ian skerrit 이클립스를 사용하는 개발자의 64%가 윈도우즈를 사용하고 27%가 리눅스를 사용하고 있다는 결과를 발표하였다. 참고로 2007년 조사결과에 따르면 윈도우즈 사용자는 74% 리눅스 사용자는 20% 였다. 상당한 개발자가 리눅스를 개발환경으로 이동되었음을 알 수 있다.

deployment 플랫폼으로 보자면 리눅스가 43%로 41%의 윈도우를 앞지르고 있다.

개발자 커뮤니티는 데스크탑 개발환경과 deployment 개발환경을 지속적으로 리눅스로 바꾸어나가기 때문인 것으로 보고 있다. Skerrit는 그의 블로그에서 우분투와 레드햇으로의 이동은 분명한 이득을 주지만 윈도우즈는 그러하지 못하기 때문이라고 그 이유를 설명한다.

이러한 결과가 발생한 또 다른 이유는 리눅스 친화적인 Mysql과 Oracle과 같은 데이터베이스의 점유율 때문이다. 이들 두 데이터베이스의 점유율은 55%가 넘고 있다.

또한 이번 조사 결과는 기업들이 단지 오픈소스를 사용하기만 하는데에 머무르지 않고, 오픈소스에 공헌을 하는 정도로 오픈소스에 대한 인식이 성숙되었음을 보여주고 있다.

2007년에 46%의 기업들이 OSS의 사용을 허락했지만 OSS에 대한 공헌은 이루어지지 않았다. 즉 내부적으로 OSS를 사용하기만 했다. 지금은 이 비율이 27%로 줄었다. 이제 48.2% 의 응답자들이 그들의 기업이 OSS 커뮤니티로의 지원을 허락하고 있다고 응답을 하고 있다. 2007년의 37%에 비하면 10%나 증가한 수치다. - 국내의 경우에도 대략 2007년과 2008년을 기점으로 기업들의 오픈소스에 대한 직접적인 참여와 지원이 늘어나고 있다. -. OSS를 통한 비지니스 모델에 기대를 걸고 있다는 응답도 2007년 10%인 것에서 2008년 15.6%로 대폭 증가했다.

2 The Open Source Developer Report 2009

이 문서는 2009년 Eclipse Community 의 보고서인 The Open Source Developer Report를 보고 정리했다.

2.1 핵심 내용

이 보고서는 다음과 같은 핵심내용을 포함하고 있다.

• 리눅스는 데스크탑과 서버 환경모드를 공유하고 있다. 개발자들이 개발을 위한 데스크탑운영체제로 Microsoft 윈도우즈에서 리눅스와 Mac OX로의 이동하는 모습이 분명히 감지되고 있다. 특히 depolyment 운영체제환경으로 리눅스는 가장 일반적인 플렛폼이 되었다.
  
• Mysql 과 Oracle 데이터베이스는 55%이상의 지배적인 점유율을 보여주고 있다.
  
• 형상관리도구로는 SVN(Subversion)이 57% 점유율을 보여주고 있다.
  
• 기업은 성숙한 OSS 모델을 받아들이고 있다.
  
  1. 더 많은 기업들이 오픈소스 소프트웨어의 사용과 기여에 참여하고 있다. 보고서에 따르면 2008년 48.2%였다. 2007년에는 37%였다.
     
• 15.6 %의 회사가 OSS에 연계한 비지니스 모델을 만들고 있다.
  
  

3 보고서 참여자 통계 자료

응답자의 반이상이 프로그래머였으며 기타 시스템 아키텍쳐, 매니저, 소프트웨어 품질관리 및 테스터, 마케팅 메니저 등이 참여하였다.

4 개발자 데스크탑 개발 환경

개발자가 사용하는 데스크탑 운영체제 통계정보를 보여주고 있다. 윈도우즈에서 Linux와 Mac OSX로 이동하는 것을 확인할 수 있다. 26.9%의 개발자가 주요 개발 데스크탑 환경으로 리눅스를 사용하고 있다고 응답했는데, 2007년에 비하면 7%가 증가한 수치다.

2007년에 비하면 10%가량 줄어들긴 했지만, 여전히 윈도우즈는 64%의 사용율을 가지는 지배적인 운영체제다. 가장 많이 사용되는 리눅스 배포판은 Unbuntu인 것으로 조사되었다. Mac OSX도 2007년 3.5%에서 6.9%로 증가했다.

1. Windows Server or Client : 64.3%
   
2. Linux : 26.9%
   
   1. Ubuntu 14.5%
      
   2. Fedora 3.4%
      
   3. SUSE 3.2%
      
   4. Debian 2.6%
      
   5. RHEL 1.3%
      
   6. 기타 배포판 1.8%
      
3. Mac OSX : 6.9%
   
4. Sun Solaris or OpenSolaris : 0.9%
   
5. Other : 0.8%
   

4.1 IDE : 통합개발 환경

Eclipse IDE가 가장 인기있는 개발환경으로 지목되었다.

1. Eclipse JDT : 60%
   
2. Eclipse PHP 개발 툴 : 12.6%
   
3. Eclipse C/C++ 개발 툴 - CDT - : 6.3%
   

4.2 형상관리 툴

SCM(Source code management), CMS(changes management) 그리고 BM(Build management)에 대한 사용율을 조사한 자료다.

5 언어 및 응용프로그램

자바는 커뮤니티에 의해서 주도적으로 사용되는 언어였으며, 76.6%가 그들의 첫번째 언어로 자바를 사용한다고 응답했다. 개발용도는 Server-Centric 30.2%, 웹이 24.7%, 데스크탑 애플리케이션이 23.4%였다.



이 보고서는 주요 3가지 개발용도에 대해서 각각 어떠한 툴 혹은 언어를 사용하는지에 대해서 조사했다.

5.1 Server-Centric 애플리케이션

server-centric 애플리케이션의 개발을 위해서 가장 널리 사용되는 되는 것은 servlet이였다. 그다음으로는 spring 프레임워크였으며, EJB도 38.3%로 널리 사용되는 것으로 조사되었다. 대표적인 server-centric 애플리케이션은 J2EE 애플리케이션, 데이터베이스 애플리케이션, ERP, CRM 등이 있다.

5.2 Web, Rich 인터넷 애플리케이션

웹과 rich Internet 애플리케이션 (RIAs)의 경우에는 주도적인 프레임워크나 툴이 없는 것으로 조사되었다. 오픈소스 Ajax 프레임워크, Flash/Flex 등이 많이 사용되었으며, 아예 사용하지 않는 다는 응답도 꽤 되었다. GWT가 많이 사용되고 있다는 점이 눈에 띈다.

5.3 Rich Desktop Applications

Eclipse RCP (47.6%)와 Swing (43.8%)로 양분되어 있는 모습을 보여주고 있다.

6 Deployment 환경

개발자들이 그들이 개발한 애플리케이션이 설치될 타겟 환경으로 어떠한 것을 이용하는지에 대한 조사내용을 포함하고 있다. 운영체제, 데이터베이스 그리고 애플리케이션 서버 환경에 대해서 조사를 했다.

리눅스는 주목할만한 Depolyment 타겟 운영체제로 성장을 했으며, 지금은 오히려 윈도우를 앞서고 있는 것으로 확인되었다. 2008년 기준 42.7%의 점유율을 보여주고 있는데 2007년의 37%에 비하면 5%가까이 증가한 수치다. Ubuntu(12%), Red Hat Enterprise Linux (10.2%) 배포판이 널리 사용되고 있었다. 결과를 보면 윈도우환경의 유저가 리눅스, Mac OSX 등으로 이동한 것으로 보인다.

6.1 주요 데이터 베이스

예상대로 Mysql 과 Oracle이 각각 27.7%와 27.3%로 주요하게 사용되고 있었다. Mysql과 Oracle은 선호대상이 갈리는 것이 확인 되었다. 기업규모로 보자면, 5000 명 이상을 고용하고 있는 거대 기업의 경우에는 Oracle이 33.5%, IBM DB2가 10.7%, Mysql 이 11.6% 였다.

Oracle은 다음과 같은 선호대상층을 가진다.

• Java를 주요 개발언어로 사용하는 경우
  
• server-centric 애플리케이션을 개발하는 경우
  
• Application 서버를 이용하는 경우
  
  

Mysql은 다음과 같은 선호대상층을 가진다.

• PHP 언어를 주요언어로 사용하는 개발자
  
• RIA/Web 애플리케이션
  
  

6.2 주요 Application 서버

Apache Tomcat이 가장 널리 사용되고 있다. 그다음으로 JBoss, IBM WebSphere가 사용되고 있다. 아무 것도 사용하지 않는다는 응답도 25.3%나 되었다. 5000명이상 고용인을 가진 대기업의 경우에도 여전히 Apache Tomcat이 가장 널리 사용되었으나 IBM WebSphere가 6.9%에서 12.0%로 크게 오르고 Apache Tomcat 는 34.8%에서 26%로 떨어진걸 확인할 수 있었다.

7 평가

몇년전만 하더라도 오픈소스는 기업에서는 받아들이기 힘든 모델이라고 평가되기도 했었다. 혹은 많은 기업들이 단지 오픈소스의 단물만 빨아먹으려고 할뿐 결코 오픈소스 모델에 참여하지는 않을 것이라고 생각되던 때도 있었다.

그러나 이 보고서에 따르면, 오픈소스는 메이저한 개발/배포 환경은 물론이고 비지니스 환경까지 그 영역을 지속적으로 확장시켜가고 있음을 확인할 수 있다. 더불어 분명하게 더 많은 기업들이 적극적으로 오픈소스 모델에 직접적으로 참여하고 있는 것도 확인할 수 있다.

대세는 OSS

저작권의 출현

지각문화

책 파괴의 세계사 ISBN : 8991482163 를 읽고

가장 많은 책을 파괴한 집단

은 역시 종교집단. 그 중에서도 유일신을 믿는 종교집단이다. 이 책을 읽다보면 수많은 책을 파괴한 종교의 야만적인 행위에, 분노게이지가 차곡차곡 쌓이는걸 느끼게 될 것이다. 책 부제도 책 파괴의 야만적인 역사 이다. 나 이외의 다른 신을 두지 말라라 는게 유일신교의 제일 교리이기도 하고 다른신을 상징하는 것은 물건이건 책이건 간에 모조리 불태워 없애라고 했으니 그럴수 밖에 없었을 것 이라고 이해해줘야 하는건가? 그 다음이 아마 전쟁과 독재자들 때문이였던 것으로 생각된다. 전쟁을 버린 이유의 상당부분이 종교문제 때문 이였을 테니 역시 책을 파괴한 제일 원흉?은 종교집단인게 분명해 보인다. 이외에 홍수,지진,화산폭발,좀벌레,습기 같은 것들이 있긴 했지만 예상외로 자연재해로 책이 파괴된 것은 약 30%정도에 불과한 것으로 이 책은 설명하고 있다.

유일신교, 독재자, 전쟁광의 공통점은 타인을 타인의 사상을 인정하지 않는다는 점일 것이다. 뭐 종교인이야 독재자와 전쟁광과는 목적이 다르다라고 주장할 수도 있을 것이다. 더 아름다운 세상을 만들기 위해서 !!. 신이 잘못된게 아니고 인간이 잘못된 것이다라고 할 수도 있겠으나, 종교집단이 책을 비롯한 수많은 문화유산을 파괴한건 사실이니 때로는 비난을 피해가기 힘들 것이다. 지금은 뜸하지만 멀쩡한 20세기 민주국가라고 하는 대한민국에서도 그러한 일이 벌어졌기도 했고 말이다.

하긴 유일신 야훼는 바이러스와 야동이 설쳐대는 세상을 더이상 보지 못하여서 물로 깨끗하게 포맷까지 해버리지 않았는가.

책에 적혀 있었다

책을 파괴하고자 하는 이유는 책에 그러하게 적혀있었다라고 하면 진실처 럼 생각을 하기 때문이다. 사실과 진실은 다르다. 책에 사실이 적혀있었다고 하더라도 그것이 진실인 것은 아니다. 신자유주의를 도입한 이래 성공적으로 성장을 한 국가의 예를 들어서 신자유주의를 옹호하는 책이 있다고 생각해 보자. 이것은 사실이다. 그러나 반대로 신자유주의가 도입된 이후 오히려 삶의 질이 현저히 떨어진 국가와 계급을 예로 들면서 신자유주의에 반대하는 책이 있다. 이것도 사실이다. 그럼 뭐가 진실인가 ?

그 판단은 책을 읽는 사람의 몫이다. 그러나 독재자는 여러가지 사실이 존재하는걸 싫어 한다. 자신이 제시하는 하나의 사실만이 존재하길 한다. 사실이 하나라면 그게 곧 진리가 되지 않겠는가 ? 자유민주주의사회는 여러가지 사실이 존재한다는 것을 인정한다. 이런 이유로 모든 독재자가 반민주적인 것은 필연적일 수 밖에 없는 것이다. 그러니 무뉘만 민주주의 대한민국에서 나쁜 사마리아인과 같은 책이 국방부 지정 금서목록씩이나 되는 것이다. 헤게모니를 쥐고 있는 자본가들에게 또다른 사실을 말해주는 그러한 책이 여엉 불편한 것이다. 뭐 불편할 수도 있다. 불편한 사실이라는 것도 있으니까. 문제는 자신들의 힘을 이용해서 불편한 사실을 통제하고 마음편한 사실만 유통되도록 통제하려고 하는데에 있다.

그래서 그들은 책을 불태우고 금서목록을 만들고 인터넷에 대한 통제를 시도한다. 정보통제, 정보파괴는 고금을 통틀어 독재자의 공통분모다. 물론 걔들은 얘기한다. 세상이 시끄러워진다고. 지금의 이 정부도 그러한 생각으로 정보를 통제하고, 금서목록을 생산해 내시고 계신다.

인터넷 시대의 정보파괴 행위

과거에는 정보를 차단하고 파괴시키는게 비교적 쉬웠을 것이다. 책은 소수의 필사자에 의해서 엄청난 공을 들여서 오랜시간에 걸쳐 만들어 졌다. 복사라는 개념자체가 없었으니 복사본이 돌아다니는 것도 아니다. 사상가 몇명 잡아서 족치고, 여기 저기 돌아다니는 몇개 안되는 책 불태우고 필사자들 몇명 관리하면 그걸로 끝이었다.

매체 기술은 흔히 대량의 복사, 빠른 전달이 가능한 방향으로 발전을 하는 것 같다.

대부분의 정보가 인터넷에서 실시간으로 그리고 무한대로 복사되는 지금에 와서 정보를 통제한다는 것은 기술적으로 거의 불가능 하게 되었다. 고작해야 조금 귀찮게 하는 정도라고나 할까 그 정도다. 그래도 2MB 정권은 통제를 하려고 하신다. 이러니 youtube 실명확인 거부와 같은 헤프닝이 북한도 아니고 중국도 아닌 대한민국에서 벌건 대낮에 벌어지고 있다.

전자책이 책파괴의 역사를 근절시켜 줄 것인가 ?

다시 책파괴 얘기로 되돌아와서 그렇다면 전자책이 책파괴의 역사를 근절시켜줄 수 있을까 ? 독재스러운 얘들 혹은 광신스러운 얘들에게서 책을 지켜줄 수 있을까 ?

전자책이 그러한 과업을 수행하기엔 힘이 부칠 것이라는 예상을 하는 사람들도 있다. 여기에는 몇 가지 이유가 있다. 최신 기술이라고 하는 것들이 종이책에 비해서 그다지 내구도가 높지 않다는게 아마 가장 큰 이유일 것이다. 최신 저장매체가 종이보다 내구도가 높지 않다는 것은 사실인 것 같다. 종이책의 경우 습기, 좀벌레와 같은 적들이 내구도를 깍아 먹는다고 하더라도 전쟁과 같은 적대적인 파괴행위가 없다면 수백년은 어렵지 않게 보관이 가능하다. 여기에 좀더 관심을 가진다면 천년이 넘는 시간도 버텨낼 수 있을 것이다. 집에 뒹굴어 다니는 책들의 경우에도 책장에만 잘 꽂아주는 정도로 수십년 혹은 백년이상 좋은 상태로 보관이 가능 하리라 생각된다.

CD 혹은 DVD에 정보를 저장하면 반 영구적으로 보관할 수 있을 것이라고 선전한다. 지금에 와서야 이 거짓말을 믿는 사람은 없을 것이다. 종이보다도 훨씬 내구도가 떨어지는게 디지털 저장매체들이다.

그렇지만 이들 디지털 매체는 쉽게 복사 가능하다는 특징으로 물리적 내구도를 크게 향상시킬 수 있다는 점이 간과되어서는 안될 것이다. 디지털 정보는 아날로그 정보에 비해서 보기가 불편하다는 문제도 조금씩 해결 되고 있다.

cool ebook from seppelpeppel on Vimeo.
책의 저자는 디지털로 된 책이 저장되는 천국의 도서관을 상상한다. 책을 읽고자 하는 사람은 언제든지 쉽게 다운로드 받아서 자신의 단말기를 통해 읽어 볼 수 있다. 이 천국의 도서관은 게다가 여러곳에 분산되어서 위치할 수 있으므로, 지구적인 재앙이 일어나기 전에는 완전히 사라지지 않을 것이다. 네트워크 환경이 충분히 갖추어져 있다면, 위키피디아에서 처럼 손실된 정보를 사람들이 다시 복구할 수도 있을 것이다.

지금 구글과 아마존이 그러한 작업을 하고 있다.

내 생각에 가까운 미래의 도전할만한 인터넷 서비스는 전자책분야일 것 같다. 요즘 이쪽에 부쩍 관심이 간다.

관련글

• 킨들 전자책 리더
  
• Electronic paper
  
• 60억 달러 e북 전쟁 시작됐다
  
• 삼성전자 e북 파피루스 6월 출시
  
• DBR 전자책 대중화 꿈이 무르익는다.
  

아오.. 일단 포스팅 하고 보자..

1 Thread에 대해서

프로그램을 병렬로 실행시키는 방법으로 fork()에 대해서 알아보았다. fork()는 매우 이해하기 쉬운 프로그래밍 방법이긴 하지만 자원효율성에서 몇가지 문제점을 가지고 있다. 프로세스는 기본적으로 code, data, stack, file I/O, 그리고 signal table의 5가지 요소로 구성이 된다. fork() 를 이용해서 새로운 프로세스를 생성하게 되면, 이러한 5가지 구성요소가 모두 복사가 된다. 그러하다 보니 프로세스를 생성하는데 많은 비용이 소비될 것이다. 대게의 경우에는 프로세스를 새로 생성시킬때 발생하는 성능저하가 문제가 되지는 않겠지만 웹서비스처럼 대량의 접근이 발생하는 영역에서는 문제가 될 수 있다.

fork의 이러한 방식은 상당히 효율이 떨어지는 측면이 있다. 어떤 프로그램을 병렬로 실행시킨다고 했을 때, 실제 우리가 병렬로 실행되기를 원하는 영역은 코드의 일부분이지 프로그램 전체는 아니기 때문이다.

// ... 
pid = fork(); 
if (pid > 0) 
{ 
    // 실제는 이 부분의 코드만 병렬로 실행되면 된다. 
    // fork()는 다른 모든영역의 코드가 복사되어 버린다. 
} 
 

게다가 전혀다른 프로세스를 생성시킴으로써, 프로세스간 통신이라는 상당히 복잡한 문제까지를 해결해야 한다. 병렬로 작동하는 프로그램은 특성상 데이터를 공유하거나 서로 통신을 해야 하는 경우가 많다. 그런데 프로세스는 서로 독립된 객체이므로 일반적인 방법으로는 데이터를 공유할 수가 없다. 이러한 프로세스간 데이터 통신을 위해서 리눅스는 IPC라는 설비를 제공하는데, IPC라는게 사용하기가 여간 까다롭지가 않다. IPC에 대해서는 별도의 장을 할애해서 다룰 계획이다.

Thread를 이용하면 fork()를 이용한 프로세스 기반의 병렬처리의 문제점의 많은 부분을 해결할 수 있다. Thread는 새로운 프로세스를 생성시키지 않고, 특정 문맥(코드)만을 병렬로 실행할 수 있도록 허용한다. 새로운 프로세스를 생성시키지 않기 때문에 그만큼 자원을 아낄 수 있으며, 더 효율적으로 빠르게 움직일 수 있다. 또한 같은 프로세스이기 때문에, 데이터를 공유하기가 쉽다는 장점도 가진다.

1.1 Thread vs Process

Thread는 프로세스와 다음과 같은 차이점을 가진다.

• 프로세스는 독립적이다. 쓰레드는 프로세스의 서브셋이다.
  
• 프로세스는 각각 독립적인 자원을 가진다. 쓰레드는 stat, memory 기타 다른 자원들을 공유한다.
  
• 프로세스는 자신만의 주소영역을 가진다. 쓰레드는 주소영역을 공유한다.
  
• 프로세스는 IPC를 이용해서만 통신이 가능하다.
  
• 일반적으로 쓰레드의 문맥교환(context switching)는 프로세스의 문맥교환보다 빠르다.
  
  

1.2 Multi Thread 프로그램의 단점

모든 도구가 그러하듯이 Multi Thread 프로그램이라고 해서 장점만 가진 것은 아니다. Multi Thread 프로그램은 Multi Process 프로그래밍 방식에 비해서 다음과 같은 단점을 가진다.

• 하나의 쓰레드에서 발생된 문제가 전체 프로세스에 영향을 미친다.
  
  멀티 프로세스의 경우에는 프로세스하나가 문제가 생기더라도 단일 프로세스로 문제가 제한된다. 그러나 멀티쓰레드 프로그램의 경우 하나의 쓰레드에 생긴 문제가 다른 쓰레드에까지 영향을 줄 수 있다. 예를 들어 쓰레드 하나가 다른 프로세스의 메모리 영역을 침범할 경우 프로세스 자체가 죽어버림으로써, 프로세스에 생성된 다른 모든 쓰레드도 프로세스와 함께 죽어버리게 된다. - 이 문제는 해결 가능하지만 여기에서는 다루지 않도록 하겠다. 시그널을 잘 활용하면 된다. 관심있으면 한번 고민해 보기 바란다. -
  
• 디버깅이 어렵다. 문맥이 서로 교환되므로 추적하기가 까다롭다.
  
  

이러한 단점이 있음에도 불구하고 멀티쓰레딩 프로그래밍 기법을 선호하고 있다.

1.3 PThread

Thread는 운영체제에서 제공하는 병렬처리 메커니즘으로, 실제 이 메커니즘을 이용하기 위해서는 Thread의 구현체가 필요하다.

리눅스에서는 pthread라는 thread 구현 라이브러리가 사용되고 있다. pthread는 POSIX thread 의 줄임말로 POSIX 표준을 따르고 있다. pthread는 리눅스 뿐만 아니라 다른 거의 대부분의 유닉스에서도 사용할 수 있다. 이외에도 BSD 계열에서 사용하는 'Light Weight Kernel Threads , Apple 에서 사용하는 Multiprocessing Services등의 구현체가 있다. 이 문서는 pthread구현만을 설명하도록 할 것이다.

pthread는 리눅스 운영체제에서 제공하는 thread 를 제어하기 위한 함수들을 모아 놓은 C 라이브러리로, 다음과 같은 기능의 함수군을 제공한다.

• 쓰레드 생성과 종료 관련 함수들
  
• 쓰레드 동기화 관련 함수들
  
  쓰레드는 많은 데이터를 공유한다. 그러므로 데이터에 대한 동기화 문제를 해결해야할 필요가 있다.
  
• 쓰레드 시그널 제어 함수들
  
  signal은 프로세스단위로 작동한다. 그러나 쓰레드 프로그램의 경우, 각 쓰레드 마다 다른 시그널 정책이 필요하므로, 쓰레드 전용의 시그널 제어 함수가 필요하다.
  
  

1.4 Multi Thread 프로그램

병렬로 작동하지 않는 하나의 문맥흐름만을 가지는 프로그램을 단일 쓰레드 프로그램이라고 한다. 반대로 아래와 같이 문맥이 나뉘어서, 동시에 두개 이상의 쓰레드가 실행되면, 이를 멀티 쓰레드 프로그램'''이라고 한다.

1.5 Process, Kernel Thread, User Thread

프로세스는 가장 무거운 커널의 스케쥴링 단위이다. 프로세스는 운영체제에게 할당받은 자원들 - 파일 핸들러,소켓,장치 핸들러 - 을 할당받게 된다. 프로세스는 독립된 단위로써 파일이나 주소영역 등을 공유하지 않는다.

kernel thread는 가장 가벼운 커널 스케쥴링 단위다. 하나의 프로세스는 적어도 하나의 커널 쓰레드를 가지게 된다. 만약에 프로세스가 하나이상의 쓰레드를 가지고 있다면, 이들 쓰레드는 같은 메모리와 파일자원등을 공유하게 된다. 만약 커널의 프로세스 스케쥴러가 선점형이라면 쓰레드의 스케쥴러도 선점형인 경우가 많다. 참고삼아서 선점형과 비선점형에 대해서 간략하게 설명하도록 하겠다.

• 비선점형 : 특정 프로세스가 CPU를 독점하는 것이 가능하다.
  
• 선점형 : 특정 프로세스가 CPU를 독점하는게 불가능하다.
  

특정 프로세스가 CPU를 독점하는게 불가능하게 하는 것은 프로세스가 인터럽트를 무시하기 못하게 하는 것으로 구현한다. 선점형은 어떤 프로세스가 시스템콜을 수행중이더라도 커널이 인터럽트를 보내면, 즉시 빠져 나와야 한다. 즉 운영체제가 CPU를 선점한다는 얘기가 된다. 시스템콜이 수행중이더라도 인터럽트를 걸고 다른 일을 수행하도록 할 수 있으므로 보다 빠른 반응성을 보여준다.

때때로 쓰레드가 유저영역 라이브러리로 구현되는 경우가 있는데, 이를 user Thread 라고 부른다.

1.6 쓰레드의 생성과 종료

멀티 쓰레드 프로그램이라고 하더라도, 처음 시작되었을 때는 main()에서 시작되는 단일 쓰레드 상태로 작동이 된다. 이 상태에서 pthread_create(3) 함수를 호출함으로써, 새로운 쓰레드를 생성할 수 있다. pthread_create를 이용해서 생성된 새로운 쓰레드를 worker 쓰레드라고 하자.

멀티 쓰레드 프로그램은 다음과 같은 흐름을 가진다.



생성된 worker thread는 언젠가 종료가 될 것이다. Master Thread (이하 부모 쓰레드)는 pthread_join()을 이용해서 worker thread들의 종료를 기다린다. pthread_join()는 종료된 worker thread의 자원을 정리하는 일을 한다. fork()를 이용한 멀티 프로세스 프로그램에서, 부모 프로세스가 wait()를 이용해서 자식 프로세스를 기다리는 것과 같은 이유라고 보면 된다.

1.6.1 pthread_create : 쓰레드 생성

pthread_create(3)함수를 이용하면 새로운 쓰레드를 생성할 수 있다. 이 함수는 다음과 같이 사용할 수 있다.

#include <pthread.h> 
 
int  pthread_create(pthread_t  *  thread, pthread_attr_t *attr,  
     void * (*start_routine)(void *), void * arg); 
 

1. thread : 쓰레드가 성공적으로 생성되었을 때, 넘겨주는 쓰레드 식별 번호.
   
2. attr : 쓰레드의 특성을 설정하기 위해서 사용한다. NULL일 경우 기본 특성
   
3. start_routine : 쓰레드가 수행할 함수로 함수포인터를 넘겨준다.
   
4. arg : 쓰레드 함수 start_routine를 실행시킬 때, 넘겨줄 인자
   

이 함수는 성공적으로 수행되었다면, 0을 리턴한다. 그렇지 않을 경우 1을 리턴한다.

1.6.2 pthread_join : 쓰레드 정리

쓰레드가 실행시키는 것은 함수 이다. 그러므로 return이나 exit(0)등을 이용해서 쓰레드를 종료시킬 수 있게 된다. 그러나 쓰레드 함수가 종료되었다고 해서 곧바로 쓰레드의 모든자원이 종료되지 않는다. fork()기반의 멀티프로세스 프로그램에서 종료된 자식프로세스를 정리하기 위해서 wait()로 기다리듯이, 종료된 쓰레드를 기다려서 정리를 해주어아만 한다. 그렇지 않을 경우 쓰레드의 자원이 되돌려지지 않아서 메모리 누수현상이 발생하게 된다.

pthread_create()로 생성시킨 쓰레드는 pthread_join()을 통해서 기다리면 된다. pthread_join 함수는 다음과 같이 사용할 수 있다.

#include <pthread.h> 
 
int pthread_join(pthread_t th, void **thread_return); 
 

1. th : pthread_create에 의해서 생성된, 식별번호 th를 가진 쓰레드를 기다리겠다는 얘기다.
   
2. thread_return : 식별번호 th인 쓰레드의 종료시 리턴값이다.
   
   

pthread_join이 하는 일은 명확하다. 다만 주의 할것은 pthread_join은 반드시 joinable 한 상태로 생성된 쓰레드만을 기다릴 수 있다는 점이다. pthread_create로 쓰레드를 생성시킬 때, 나중에 join되지 않을 것으로 생각하고 생성시킬 수 있는데, 이렇게 되면 이 쓰레드는 종료하자마자 모든 자원을 해제하며, pthread_join으로 기다릴 수가 없다. 부모쓰레드와 떨어져서 완전히 독립적으로 작용한다고 하여, 이를 detach 한다고 한다. 쓰레드를 detach하는 방법은 아래에서 다룰 것이다.

1.6.3 쓰레드 생성 예제

pthread_create와 pthread_join을 알고 있다면, 이제 thread를 생성시킬 수 있다.

#include <pthread.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <stdlib.h> 
 
// 쓰레드 함수 
void *t_function(void *data) 
{ 
    int id; 
    int i = 0; 
    id = *((int *)data); 
 
    while(1) 
    { 
        printf("%d : %d\n", id, i); 
        i++; 
        sleep(1); 
    } 
} 
 
int main() 
{ 
    pthread_t p_thread[2]; 
    int thr_id; 
    int status; 
    int a = 1; 
    int b = 2; 
 
    // 쓰레드 생성 아규먼트로 1 을 넘긴다.   
    thr_id = pthread_create(&p_thread[0], NULL, t_function, (void *)&a); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 쓰레드 생성 아규먼트로 2 를 넘긴다.  
    thr_id = pthread_create(&p_thread[1], NULL, t_function, (void *)&b); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 쓰레드 종료를 기다린다.  
    pthread_join(p_thread[0], (void **)&status); 
    pthread_join(p_thread[1], (void **)&status); 
 
    return 0; 
} 
 

아주 전형적인 프로그램이긴 하지만 pthread_join부분에 문제가 있다. pthread_join은 쓰레드가 종료될 때까지 블럭되기 때문이다. 이래서는 쓰레드를 두개이상 생성시키지 못할 것이다. 그렇다고 pthread_join을 이용하지 않는다면, 메모리 누수가 생기게 되니, 생략할 수도 없는 노릇이다.

1.6.4 자식쓰레드를 부모쓰레드로 부터 분리하기

pthread_join의 사용으로 발생할 수 있는 문제점을 해결하기 위한, 가장 좋은 방법중의 하나는 pthread_detach 를 이용해서, 자식 쓰레드를 부모쓰레드와 완전히 분리해 버리는 방법이다. 이 경우 자식 쓰레드가 종료되면, 모든 자원이 즉시 반환된다. 반면, 자식 쓰레드의 종료상태를 알 수 없다는 문제가 발생한다. 대게의 경우 자식 쓰레드의 종료상태가 중요한 문제가 되지는 않을 것이다.

만약 자식 쓰레드의 종료상태를 알아내는게 중요하다면, 종료상태를 저장할 전역변수를 두고, 여기에 종료상태를 기록하는 방식을 사용할 수 있을 것이다. 자식 쓰레드가 종료할때, 변수의 값을 바꾸고, 부모쓰레드에 시그널을 전송하는 방법이다. 이 방법은 이 문서의 뒤에서 따로 다루도록 하겠다.

#include <pthread.h> 
#include <stdio.h> 
#include <unistd.h> 
#include <stdlib.h> 
 
// 쓰레드 함수 
// 1초를 기다린후 아규먼트^2 을 리턴한다. 
void *t_function(void *data) 
{ 
    char a[100000]; 
    int num = *((int *)data); 
    printf("Thread Start\n"); 
    sleep(5); 
    printf("Thread end\n"); 
} 
 
int main() 
{ 
    pthread_t p_thread; 
    int thr_id; 
    int status; 
    int a = 100; 
 
    printf("Before Thread\n");  
    thr_id = pthread_create(&p_thread, NULL, t_function, (void *)&a); 
    if (thr_id < 0) 
    { 
        perror("thread create error : "); 
        exit(0); 
    } 
 
    // 식별번호 p_thread 를 가지는 쓰레드를 detach  
    // 시켜준다. 
    pthread_detach(p_thread); 
    pause(); 
    return 0; 
} 
 

1.7 쓰레드 동기화

이제 우리는 간단한 다중쓰레드 프로그램을 만들 수 있게 되었다. 그러나 이들 쓰레드 생성 함수만 가지고는 복잡한 쓰레드 프로그램을 만들 수가 없다. 쓰레드간 동기화라고 하는 문제가 놓여있기 때문이다. 아주 간단한 프로그램이 아닌한은 반드시 동기화문제를 고민해야만한다.

동기화란 여러가지 의미로 사용될 수 있는데, 이 경우에 있어서 동기화는 서로의 시간을 맞춘다를 의미한다. 멀티쓰레드 프로그램은 하나의 시간에 여러개의 프로세스가 돌아가는 형태를 취한다. 또한 멀티쓰레드 프로그램은 자원의 상당부분을 서로 공유하는 경우가 많다. 만약 단지 자원을 읽어들이는 거라면 상관없지만 읽고/쓰는 것이라면 동기화와 관련된 문제가 발생할 수 있다.

예컨데 다음과 같은 경우다.

1. A와 B 두개의 프로세스가 있다. 이 프로세스는 int count=1 이라는 자원을 공유한다.
   
2. A가 count를 읽어들이고 1을 더한다.
   
3. B가 count를 읽어들인다. 아직 A가 count에 쓰지 않았기 때문에, B도 1을 읽어들인다.
   
4. A가 count에 2를 쓴다.
   
5. B도 count에 2를 쓴다.
   
6. count에는 2가 저장되었다.
   

우리가 원하는 값은 2가 아닌 3이다. 그러나 쓰레드가 동기화 되지 않음으로써, 원치않은 잘못된 연산을 하게 되었다. 우리는 이 문제를 해결해야 한다.

1.8 접근제어

동기화 문제는 현실세계에서도 자주 발생한다. 화장실을 생각하면 된다. 화장실은 공유자원이며, 여러명이 사용한다. 누군가 화장실을 사용하고 있다면, 다른 사람은 화장실을 사용하면 안된다. 이 문제를 우리는 접근을 제어하는 방식으로 해결한다. 문을 걸어 잠궈서 한번에 한사람만 화장실에 들어가도록 하는 방법이다. 매우 이해하기 쉬운 방식이다.

다중쓰레드 프로그램에서도 마찬가지로 접근제어를 이용해서 이 문제를 해결한다. 이를 위해서 pthread는 mutex라는 잠금 메커니즘을 제공한다.

1.8.1 mutex 잠금

동시에 여러개의 쓰레드가 하나의 자원에 접근하려고 할때 발생하는 문제를 pthread는 임계영역을 두는 것으로 해결하고 있다. 임계영역안에는 접근하고자 하는 자원이 놓여있고, 오직 하나의 쓰레드만 임계영역안으로 진입할 수 있도록 제한한다. pthread는 이를 위해서 mutex를 제공한다. mutex는 그 자체가 가지는 잠금의 특성 때문에 mutex 잠금이라고 불리워지기도 한다.



위 그림은 mutex가 작동하는 방식을 보여준다. thread 1이 자원에 접근하면 mutex 잠금을 얻게 된다. 이 잠금은 단지 하나만 존재하기 때문에 thread 2는 잠금을 얻지 못하고 임계영역 밖에서 대기하게 된다. thread 1이 자원을 모두 사용하고 임계영역을 벗어나면 thread 2는 잠금을 얻게 되고 임계영역에 진입해서 자원을 사용할 수 있게 된다.

1.8.2 mutex의 사용

mutex를 사용하기 위해서는 다음의 4가지 함수가 필요하다.

• mutex 잠금객체을 만드는 함수
  
• mutex 잠금을 얻는 함수
  
• mutex 잠금을 되돌려주는 함수
  
• mutex 잠금객체를 제거하는 함수
  
  

1.8.3 pthread_mutex_init

mutex를 사용하기 위해서는 먼저 pthread_mutex_init() 함수를 이용해서, mutex 잠금 객체를 만들어줘야 한다.

pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutex_attr *attr); 
 

이 함수는 두개의 인자를 필요로 한다.

1. mutex : mutex 잠금객체
   
2. mutex_attr : mutex는 fast, 'recursive, error checking의 3종류가 있다. 이 값을 이용해서 mutex 타입을 결정할 수 있다. NULL 일경우 기본값이 fast가 설정된다.
   
   • fast : 하나의 쓰레드가 하나의 잠금만을 얻을 수 있는 일반적인 형태
     
   • recursive : 잠금을 얻은 쓰레드가 다시 잠금을 얻을 수 있다. 이 경우 잠금에 대한 카운드가 증가하게 된다.
     

mutex_attr을 위해서 다음의 상수값이 예약되어 있다.

• fast : PTHREAD_MUTEX_INITIALIZER
  
• recursive : PTHREAD_RECURSIVE_MUTEX_INITIALIZER
  
• error checking : PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
  
  

1.8.4 pthread_mutex_lock

mutex 잠금을 얻기 위한 함수다.

int pthread_mutex_lock(pthread_mutex_t *mutex); 
 

mutex 잠금을 얻는다라는 표현보다는 mutex 잠금을 요청한다라는 표현이 더 정확할 것 같다. 만약 mutex 잠금을 선점한 쓰레드가 있다면, 선점한 쓰레드가 mutex 잠금을 되돌려주기 전까지 이 코드에서 대기하게 된다.

때때로 잠금을 얻을 수 있는지만 체크하고 대기(블럭)되지 않은 상태로 다음 코드로 넘어가야할 필요가 있을 수 있을 것이다. 이 경우에는 아래의 함수를 사용하면 된다.

int pthread_mutex_trylock(pthread_mutex_t *mutex); 
 

1.8.5 pthread_mutex_unlock

mutex 잠금을 되돌려주는 함수다.

int pthread_mutex_unlock(pthread_mutex_t *mutex); 
 

1.8.6 mutex 잠금 예제

count 프로그램을 예제로 할 것이다. 임계영역안에서 보호되어야할 자원은 count이고, 여러개의 쓰레드가 count에 접근해서 +1을 시도하려고 한다. 이때 제대로된 count를 위해서는 한번에 하나의 쓰레드만이 counting을 하도록 해야할 것이다. mutex를 이용해서 임계영역을 보호하도록 할 것이다.

임계영역을 보호하지 않을 경우 다음과 같은 문제가 발생할 수도 있을 것을 예상할 수 있다.

int a = 1;  
Thread A 에서 a를 읽어들인다.  
Thread B 에서 a를 읽어들인다.  
Thread A 에서 a = a+1를 한다.  
{  
    a = a+1;  
    결과는 2;  
}  
Thread B 에서 a++를 한다.  
{  
   a = a + 1; // 읽어들인 값이 1이기 때문에  
   역시 결과는 2가 된다.  
}  
 

두번의 count가 발생했기 때문에 3이되어야 하겠지만 임계영역이 보호되지 않음으로써 2가 되어 버렸다.

mutex는 임계영역을 잠금으로서 이러한 문제를 해결한다. 이러한 문제를 해결하기 위해서는 임계영역에 단지 하나의 쓰레드만 접근하는걸 보장해줘야 할 것이다. mutex는 아래의 요소들을 보장함으로써 이를 보장한다.

• Atomicity - mutex 잠금은 최소단위 연적 - atomic operation - 을 보장한다. atomic operation에 대해서 간단히 설명하고 넘어간다. 자세한 내용은 Atomic Operation을 참고하기 바란다.
  
  1. aotomic operation은 일련의 연산 즉 mutex 잠금 연산이 끝날때 까지 다른 프로세스가 그 연산의 변화를 알 수 없는 상태가 되는 연산을 의미한다. (일반적으로 연산은 이전의 연산의 결과를 관찰한 후에서야 이루어질 수 있게다)
     
  2. 전체연산중 하나라도 실패할 경우 모든 연산이 실패하며 시스템은 전체 연산이 시작하기 전의 상태로 복구된다.
     
• Singularity : 한 쓰레드가 뮤택스 잠금을 얻었다면, 이 쓰레드가 뮤택스 잠금을 내어놓기 전까지는 다른 쓰레드가 뮤택스 잠금을 얻을 수 없도록 한다.
  
• None Busy Wait : 이것은 성능과 관련된 것이다. 바쁜대기상태에 놓이지 않는다는 뜻이다. 뮤택스 잠금을 얻을 수 있는지를 확인하기 위한 연산이 필요하지 않는 다는 의미로 받아들이면 될 것이다.
  
  

이상 mutex는 위의 3가지를 지원하는 것으로 공유되는 자원을 충돌없이 그리고 효율적으로 사용할 수 있도록 보장해준다.

다음은 mutex를 사용한 count 예제프로그램이다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

#include <stdio.h> #include <unistd.h> #include <pthread.h> int ncount; // 쓰레드간 공유되는 자원 pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; // 쓰레드 초기화 // 쓰레드 함 수 1 void* do_loop(void *data) { int i; pthread_mutex_lock(&mutex); // 잠금을 생성한다. for (i = 0; i < 10; i++) { printf("loop1 : %d", ncount); ncount ++; sleep(1); } pthread_mutex_unlock(&mutex); // 잠금을 해제한다. } // 쓰레드 함수 2 void* do_loop2(void *data) { int i; // 잠금을 얻으려고 하지만 do_loop 에서 이미 잠금을 // 얻었음으로 잠금이 해제될때까지 기다린다. pthread_mutex_lock(&mutex); // 잠금을 생성한다. for (i = 0; i < 10; i++) { printf("loop2 : %d", ncount); ncount ++; sleep(1); } pthread_mutex_unlock(&mutex); // 잠금을 해제한다. } int main() { int thr_id; pthread_t p_thread[2]; int status; int a = 1; ncount = 0; thr_id = pthread_create(&p_thread[0], NULL, do_loop, (void *)&a); sleep(1); thr_id = pthread_create(&p_thread[1], NULL, do_loop2, (void *)&a); pthread_join(p_thread[0], (void *) &status); pthread_join(p_thread[1], (void *) &status); status = pthread_mutex_destroy(&mutex); printf("code = %d", status); printf("programing is end"); return 0; }

1.9 앞으로 할 것

쓰레드는 매우 광범위한 주제로 여기에서는 쓰레드를 사용하기 위한 가장 기본적인 내용만 다루었다. 쓰레드에 대한 좀더 자세한 내용은 별도의 장을 할애해서 다룰 생각이다.