면접

보통 사람 뽑기가 힘들다고 하는데, 아마도 어떤 사람을 뽑아야 하는지에 대한 기준이 명확히 안서 있어서 일것이다. 개인적으로는 다음과 같은 기준으로 사람을 뽑기 위해 면접에 임한다.

1. 매니지먼트 없이 아웃풋을 잘 내줄 사람
2. 기존의 팀과 무리없이 엮일 사람

인데, 사실 2번은 그사람의 책임보다는 매니저의 책임이고 이런건 임원들 보고 보라고 하고, 그냥 1번만 본다. 보통 1번을 충족할 사람인지는 다음과 같은 기준의 잣대를 들이밀어 보는데..

1. 기초가 튼튼한가? (아무리 열심히 해도 기초 없는 사람들은 결과가 안나온다. 그냥 삽질하고 만다.)
2. 혼자서도 잘 컸나? (일이나 과제외에 혼자 무언가를 깨닫거나 공부/구현 한게 있는지를 살펴 본다.)

보통 1/2 번을 갖춘 사람이면 절대로 빈둥대는 법이 없고, 문제만 던져 놓으면 답을 낸다. 매니저로써의 역할은 그가 지금 일에 불만족하지 않도록 재미난 일을 만들어 내거나, 그런 일을 받아 오는 것이다.

threading

to be threaded or not?

어려운 물음이지만 threading 은 일반적으로 다음과 같은 장점을 제공한다.

1. lightweight context switching
여러 리소스를 공유하기 때문에, (특히 page table entry ) thread to thread 로 context switching 하는 것은 process to process 보다 가벼울 수 밖에 없다. CS 가 잦을수록 process model 에 비해 load 가 낮은것을 확인할 수 있다.

2. easiness of programming
memory 와 file descriptor를 share 하는 것은 여러모로 프로그래밍하기 편리하다.

3. user level mutex
기본적으로 memory variable 을 atomic 하게 억세스(고전적인 test&set 종류의 instruction) 하는것으로 mutual exclusion 을 구현할 수 있다. 그런 이유로 기본적인 mutex primitive 인 POSIX 의 pthread_mutex_lock() 이나 Win32 의 EnterCriticalSection()등 thread 에서 사용할 수 있는 mutex 들은 user level mutex 이다.
kernel level mutex 를 사용한다면, syscall overhead 와 kernel overhead 가 든다. process 에서 사용할 수 있는 mutex primitive 들은 kernel level mutex 이다. 물론 shared memory 를 사용해 process 끼리 user level mutex 를 구현할 수도 있지만...

단점은?

Heap Contention 이다. 보통 malloc 의 경우 thread safety 를 보장하지만 별로 좋은 퍼포먼스를 제공하지 않는다. 그런 이유로 heap contention 이 일어날만한 경우라면 보통 pre-allocation/pooling 으로 많이 해결하지만, 그 경우도 contention 은 충분히 문제가 될 수 있다. custom malloc 으로 heap contention 문제를 해결할 수도 있고, 다음은 그런 라이브러리중 하나다.

http://www.cs.umass.edu/~emery/hoard/