11월, 2015의 게시물 표시

최근 근황

오랜만에 글을 쓰는 거 같다..
최근 근황은 뭐 계속 회사 생활의 반복이다.. 눈깜짝하니 입사한지도 1년이 어느새 훌쩍넘었다. 뭔가 해보고 싶은게 많은데, 회사 다니면서 출퇴근 시간도 길고, 내가 체력도 안좋고 부지런한 편도 아니라서 진짜 회사만 다니기 벅찼던 것 같다.
그래도 나름 뭔가 해보려고 최근에 2가지 활동을 했었다.     그중에 하나는 컨트리뷰톤이다. 작년이나 올해 초까지만해도 오픈소스 활동을 했었는데, 회사다니면서 자연스레 멈추게 되었다. 다시 한번 오픈소스 활동을 시작하기 위한 계기를 삼으려고 컨트리뷰톤이라는 프로그램에 참여하여 uftrace 라는 C/C++ function tracing 툴 프로젝트에서 활동을 했다. 현재는 컨트리뷰톤 활동은 끝났고, 이번 달 말에 폐회식?시상식? 이 있을 예정이다.     또 하나는 블록체인 스터디이다. 반년전쯤부터인가 블록체인쪽에 관심이 생겨서 한번 공부를 해보려고 스터디를 하게 되었다. 스터디는 현재 진행형이다.
회사를 다니면서 이렇게 2가지 활동을 동시에 했다. 이 활동들에 내가 투자하려고 했던 시간/에너지 양이 대략 있었는데, 막상 해보니 실제로 투자한 시간은 내 예상의 20% 도 안되는 것 같다. 신규 기능개발로 인해 회사 일이 최근에 바쁘기도 했고, 생각보다 내가 시간과 자기관리를 제대로 못했다. 시간투자를 많이 못한게 아쉽긴 한데, 일단 뭐라도 해본 것에 의의를...
아 그리고, 최근에 우리 팀 우리 파트 채용공고를 새로 냈다. 기존의 채용 공고가 너무 모호하고 매력이 떨어진다고 생각해서 내가 건의를 해서 채용공고의 내용을 바꿔봤다.

채용공고 보기/숨기기
모집부분 - C++ 기반 공용 모듈 개선 및 개발 - C++ 기반 엔진 모듈 개선 및 개발 담당업무 - 사내 C++ 공용 라이브러리 개선 및 개발 - C++ 기반 악성코드 탐지/치료 엔진 개선 및 개발 - 코드 품질 및 개발 프로세스 개선 자격요건 - C++ 활용에 자신 있는 분 - 능동적이고 적극적으로 업무를 수행하시는 분 우대요건 …

가상화와 에뮬레이션, hypervisor, container

일단 에뮬레이션(Emulation)과 가상화(Virtualization)에 대해 알아보자. 에뮬레이션과 가상화 둘다 가상적으로 특정 시스템이 돌아갈 수 있게 하는 것이지만, 에뮬레이션은 기존의 리소스나 하드웨어를 이용하지 않고 소프트웨어적으로 구현하여 특정 시스템을 돌릴 수 있게 하는 것이다. 반면 가상화는 기존의 리소스나 하드웨어를 활용하여 시스템을 돌릴 수 있게 한다. 따라서 성능적인 면에서 가상화가 에뮬레이션보다 뛰어나지만, 가상화가 에뮬레이션보다 범위가 한정되있다고 할 수 있다. 에뮬레이션을 이용하는 것으로는 대표적으로 bochs, qemu가 있다. https://powermore.dell.com/technology/emulation-virtualization-whats-difference/
 다수의 운영 체제를 동시에 실행하기 위한 논리적 플랫폼을 하이퍼바이저(hypervisor)라고 하는데, 두가지로 분류할 수 있다.  첫 번째는 native이다. 이는 호스트OS없이 VMM이 하드웨어 위에서 직접 동작하고, 그 위에 여러개의 가상머신(OS+APP)이 동작하는 방식이다. 즉 하드웨어를 가상화하게 된다. VMware ESXi가 이에 해당한다. 이 경우에는 물리적cpu와 가상머신의 cpu가 architecture가 같아야하는등 하드웨어상의 제약이 생긴다. hosted에 비해 당연히 빠르다.  두 번째는 hosted이다. 이는 호스트OS 위에서 VMM이 동작하는 방식이다. 따라서 이 경우는 물리 컴퓨터의 하드웨어를 에뮬레이트하게 된다. 즉 하드웨어를 에뮬레이션하게 된다. 예를 들면, VMware WorkStation, VirtualBox, Qemu등이 이에 해당한다. 이 경우 호스트pc와 가상머신의 cpu architecture가 같냐 다르냐에 따라 속도가 크게 차이난다. (cpu를 에뮬레이트해야하냐 안해야하냐의 차이가 나므로..) https://superuser.com/questions/447293/does-qemus-performance-still-lag…

클라우드 서비스 IaaS, PaaS, SaaS, ASP

IaaS, PaaS, SaaS 모두 클라우드기반으로 서비스를 제공하지만 무엇을 제공하냐에 따라 나뉜다.  IaaS는 Infrastructure 즉 인프라를 제공한다. 예를 들면, Amazon EC2과 같은 클라우드 컴퓨팅 서비스가 IaaS에 해당한다. 하드웨어나 네트워크에 대한 관리부담을 갖지않고, OS를 포함해 그 상위 레벨에 대해서만 관리를 하면 된다.  PaaS는 Platform을 제공한다. 개발을 위한 플랫폼과 프레임워크등을 제공한다. 예를 들어, Azure나 오픈API등이 이에 해당한다. PaaS를 이용하면 개발자들이 OS나 플랫폼에 대한 부담없이 개발자체에 집중할 수 있다.  SaaS는 Software를 제공한다. SaaS를 이용하면 Software가 동작되고 구동되는데에 대한 어떠한 내부적인 이해없이 단순히 Web등을 통해 Software를 사용할 수 있다. 구글 App이 이에 해당한다. http://blogs.msdn.com/b/eva/archive/2012/01/16/on-premise.aspx
http://www.itworld.co.kr/news/80349 http://www.sqler.com/471632 http://www.hostway.co.kr/support/faq/iaas-paas-saas%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94
 SaaS와 ASP(application Service Provider)의 차이점에 대해서 생각해보자.  ASP는 단순히 소프트웨어가 네트워크를 통해 서비스되는 것을 말한다.  즉, 기존의 소프트웨어가 개인 PC에 설치되어 서비스되었다면, ASP는 Web등을 통해 네트워크를 통해 서비스되는 걸 말한다.  SaaS는 ASP보다 진화된 형태라고 볼 수 있을 것 같다. 예를 들면, ASP는 고객마다 instance를 하나씩 띄운다고 하면, SaaS는 하나의 instance를 통해 다수의 고객을 서비스할 수 있을 것이다.  ASP는 단순히 소프트웨어가 원격지에서 …

OOP in C

이미지
C에서도 객체지향적으로 코딩을 할 수가 있다.  하지만 C자체적으로 객체지향을 위한 키워드나 문법을 지원하지 않으므로 억지스럽고 비효율적인 측면이 있고 불가능한 부분도 존재한다.
객체지향의 핵심은 무엇일까? 1. Class (데이터 + 메소드) 와 캡슐화 2. 정보 은닉 및 추상화 3. 상속 4. 다형성 난 이 4가지가 객체지향의 핵심적인 개념이라고 생각한다.
일단 C에서 Class (데이터 + 메소드) 와 캡슐화의 개념을 implementation 하려면 설계를 객체지향적으로 하면 된다. Class같은 경우는 데이터는 구조체 안에 넣고, 메소드는 구조체이름_메소드이름 (구조체 포인터, ...) 이런 형태로 하면 된다... 만약 함수포인터를 이용하면 C++같은 문법으로 메소드를 사용할 수 도 있겠지만... 객체 만들때마다 함수포인터들을 초기화해줘야하므로 별로인 방법 같다.
추상화나 정보 은닉 같은 경우는 파일 분할과 static을 이용하면 가능하다. 아래에 그 예제가 있다.
main.c에서 6번째줄의 주석을 풀면 위와 같은 에러가 난다. main.c입장에서는 struct blackbox가 있다는 것 만 알지, struct blackbox 내부 구조를 모르므로  그 크기를 모르기 때문에 변수를 만들수가 없다. 따라서 포인터를 사용해야한다. 포인터는 무조건 크기가 정해져있으므로 타입에 상관없이 변수를 할당할 수 있다.
main.c에서 11,12번째 줄의 주석을 풀면 위와 같은 에러가 난다. 위에서 설명한 바와 같이 struct blackbox 내부구조를 모르므로 dereferencing이 불가능하다. 따라서 11,12번째줄에서 에러가 난다.
실행결과는 위와 같다.
위 코드에서는 성공적으로 private variable과 private/public method, 그리고 생성자와 소멸자를 구현했다. 하지만 제한점이 있다.  첫번째로 객체생성이 무조건 동적할당을 통해 이루어져야한다는 점이다. 구조체의 크기와 내부구조를 모르므로 객체(구조체)생성은 무조건 blackbox.…

mutex, semaphore, conditional variable, monitor의 차이점

mutex, semaphore, conditional variable, monitor의 차이점에 대해 서술해보겠다. 참고로 아래의 내용은 특정 OS에 국한된 특수한 내용이 아니라 general concept에 대한 내용이다.
  mutex는 locking mechanism이다. 즉 mutual exclusion을 위한 것으로서 lock의 owner가 존재한다. 교과서적으로는(이론적으로는) mutex와 binary semaphore를 같게 취급하는 경우도 있지만, 실제 implementation에서는 mutex는 ownership의 개념이 있다는 측면에서 다르다. binary semaphore는 누구나 up하고 down할 수 있지만, mutex는 lock의 owner만 release할 수 있다.
  semaphore는 signal mechanishm이다. semaphore count가 0일 경우 non-signaled, 1이상일 경우 signaled상태라고 할 수 있다. 누구나 semaphore count를 up 혹은 down할 수 있다. semaphore는 mutex보다 general하게 사용될 수 있다. semaphore도 locking mechanism으로서 사용될 수 있겠지만 mutex를 사용하는 것이 좀 더 옳은 방법일 것이다.    semaphore는 생산자-소비자 모델에서 활용될 수 있을 것이다. 여러개의 생산자 thread, 여러개의 소비자 thread가 있을 때 생산자는 생산이 완료되면 semaphore를 up하고, 소비자는 소비를 하기전에 down하는 식으로 생산자-소비자 모델을 구현할 수 있을 것이다.
  conditional variable은 특정 조건이 성립할 때까지 wait하고, 조건이 성립할 때 wait하고 있는 thread 1개 혹은 여러개를 깨울 수 있는 mechanism이다. conditional variable은 보통 mutex와 associated되어 사용된다. semaphore와 다른 점은 semaphore는 up한 다음…

Pintos의 conditional variable implementation에서 semaphore list를 쓰는 이유

이미지
Pintos의 threads/synch.c 의 일부이다. Pintos에서는 conditional variable을 구현하기 위해 semaphore list를 사용한다. 근데 사실 semaphore 한 개만을 사용해도 괜찮아 보일 수 있다. 어차피 semaphore 자체적으로 waiter들을 list로 관리하고, queue처럼 사용되므로 semaphore list를 사용할 필요없이 한 개의 semaphore를 가지고 conditional variable을 구현해도 상관이 없어 보인다. 하지만 이렇게 되면 cond_wait가 호출 된 후 cond_signal이 호출 됬는데, 먼저 호출된 cond_wait에서 signal을 받지 못하는 경우가 있을 수 있다. 왜냐면 lock_release를 하고 sema_down을 하게 될 텐데, lock_release 직후에 다른 thread가 스케쥴링되고 그 thread에서 cond_signal하게 되면 semaphore에 waiter가 없으므로 sema_up을 하지 않을테고 먼저의 thread는 signal을 받지 못하는 경우가 생길 수 있다. 이것이 그렇게 critical한 문제일까? lock_release시에 lock을 기다리는 thread가 없는 경우라면 아마 대부분 sema_down으로 흐름이 이어질테니까 대부분의 경우에는 문제가 안생기고 가끔 문제가 발생할 것이다. 근데 lock을 기다리고 있고 lock을 얻은 후 cpu-burst동안 cond_signal을 호출 하는 thread가 있을 경우에는 cond_wait가 평균적으로 1개의 signal을 씹을 것이다. 즉 충분히 critical한 문제라고 할 수 있다. 하지만 만약 cond_wait에서 1개 정도의 signal은 씹혀도 크게 상관없는 상황이라면 한 개의 semaphore를 가지고 conditional varaible을 구현해도 상관이 없을 것이다. 여기서 한 개의 semaphore를 가진다고 해서 conditional variable = semaphore…

이 블로그의 인기 게시물

[Effective C++ 3판] Chapter 1. C++에 왔으면 C++의 법을 따릅시다. (항목 1~4)

개발다운 개발에 대해...

최근 근황