Taeguk's Blog

일단 에뮬레이션(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-qem

 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를 통해 다수의 고객을 서비

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

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와 다른 점은 se

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 varia