synchronization

http://www.albahari.com/threading/part2.aspx

http://www.albahari.com/threading/part4.aspx#_Interlocked

lock이 참 빠른 녀석이었군..

-------------------------------------------------

1.lock 은 Monitor.Enter , Monitor.Exit 와 같다.

   하지만 lock block 안에서 exception 이 발생해도 Monitor.Exit() 를 실행해주고 ( finally block 으로 )

   코드가 더 간결해지기 때문에 좋다.

2.lock(Monitor 도 마찬가지) 에 value type 을 사용해선 안된다.

   boxing 되어 wrapper가 만들어지기 때문에 

   Enter 할때와 Exit 할때 다른 오브젝트가 넘어가게 되어 exception이 발생한다.

3. lock block 안에서 return 문을 써도 상관없다. 컴파일러가 알아서 Exit()를 호출하도록 바꾸어 준다.

4.lock 을 public 오브젝트나, 자신의 제어 밖에 있는 오브젝트에 걸면 deadlock 등의 문제가 생길 수 있다.

   private member 에 거는 것이 일반적으로 최선의 방법이다.

   lock(this) 같은 짓을 하지 말자.

   http://msdn.microsoft.com/en-us/library/c5kehkcz(v=VS.90).aspx

5.lock,Monitor,Mutex 와 같은 것들은 blocking synchronization method로 '서로 다른 쓰레드간'의 동기화를 위한 것이다.

   만약 같은 쓰레드에서 같은 오브젝트에 대해 lock을 중복해서 걸어도 dead lock은 발생하지 않는다.

   같은 쓰레드에서의 동기화가 언제 필요하냐고 물을 수 있는데, 바로 async IO 를 할 때 이다. 이는 6번에서 설명..

6.async IO ( SendAsync 류의 함수들) 를 하게 되면 IO 가 완료되었을 때 Complete event가 발생하게 된다.

   그런데 xxxAsync() 를 호출한 쓰레드와 보통 다른 쓰레드에서 Complete event가 발생한다.

   만약 Complete 되기 전에 같은 SocketAsyncEventArgs 오브젝트에 대해 xxxAsync()를 call 하면 익셉션이 발생하게 된다.

   이런 상황이 싫다면 xxxAsync 류의 함수를 쓰지 말고 synchronous 한 함수를 사용하거나 (Send() 같은 애들)

   자체적으로 동기화 처리를 해줘야 한다. ( 시작할때 lock걸고, complete 되면 lock 풀고 )

   그런데 xxxAsync()를 같은 쓰레드에서 짧은시간간격으로 호출하기 때문에 lock,Monitor,Mutex 같은 것들이 통하지 않는다.

   이럴땐 non-blocking synchronization method를 써야한다.

   Interlocked, SpinLock 클래스가 이에 해당하며 

   thread를 block 하지 않기 때문에 context-switching overhead가 없어서 성능이 더 좋다.

   하지만 SpinLock 사용시 critical section을 너무 길게 잡으면 spin overhead가 매우 커져서 오히려 손해이므로 

   critical section을 최소화 하도록 하자.

   SpinLock 클래스는 닷넷 4.0 이상에서만 제공된다.

7.lock,Monitor 가 thread 간 동기화만 가능한 반면

   Mutex는 프로세스간 동기화도 가능하다.