교착상태(Dead-lock) 회피에 대해 고민하고 있었다. 그러니까 아래와 같은 짓을 해도 괜찮은 lock manager 를 만들 생각인데... 몇가지 아이디어가 떠올랐는데 아주 값싼 처리로도 저것이 가능하다는 결론을 얻었다.
이 구현은 논리적으로 완전할 수 없는데 사유는 다음과 같다.
1. 두번째 LOCK 후에는 이전에 LOCK 한 자원들은 modify 되었을 가능성이 있다. 가령 Thread #1 에서 A 를 Lock 하고, Thread #2 에서 B 를 Lock 한 뒤에 다시 서로가 상대의 자원에 대해 Lock 을 시도할경우, 둘 중 한 Thread 는 임시로 자신이 선점했던 자원을 UnLock 하고 상대의 처리가 끝날때까지 대기해야만 한다. (Lock Manager 는 이 처리를 해주게 된다) 그리고 상대의 처리가 끝나면 다시 모든 자원에 대해 Lock() 을 걸고 다시 진행. 물론 Lock Manager 가 starve 는 막아준다. 요약해보자. 추가 Lock 을 시도할때 이전에 Lock 했던 자원이 변경될수 있다는것은 엄밀히 말하자면 이 Lock Manger 가 제공하는 Lock 은 '배타적이다' 라고는 할 수 없게 된다.
2. 'writeable' 라는 용어도 약간 다른 의미를 지닌다. 보통 'writeable' 이라 함은 해당 자원을 삭제할 권한도 가지고 있음을 뜻한다. 하지만 위와 같은 경우에서 Lock() 을 했다고 해서 자원을 삭제할 수는 없다. 왜냐하면 다른 누군가가 이미 해당 자원을 Lock 한 뒤에 나의 처리가 끝나기를 대기하고 있을 수 있기 때문이다. 해서 자원의 해제는 조금 다른 관점에서 되어야 한다.
요새는 위와 같은 내용들을 확연히 드러나게 할 수 있는 인터페이스를 고민중이다.
| Thread #1 LOCK( A ) LOCK( B ) DO_SOMETHING() UNLOCK( B ) UNLOCK( A ) | Thread #2 LOCK( B ) LOCK( A ) DO_SOMETHING() UNLOCK( A ) UNLOCK( B ) |
이 구현은 논리적으로 완전할 수 없는데 사유는 다음과 같다.
1. 두번째 LOCK 후에는 이전에 LOCK 한 자원들은 modify 되었을 가능성이 있다. 가령 Thread #1 에서 A 를 Lock 하고, Thread #2 에서 B 를 Lock 한 뒤에 다시 서로가 상대의 자원에 대해 Lock 을 시도할경우, 둘 중 한 Thread 는 임시로 자신이 선점했던 자원을 UnLock 하고 상대의 처리가 끝날때까지 대기해야만 한다. (Lock Manager 는 이 처리를 해주게 된다) 그리고 상대의 처리가 끝나면 다시 모든 자원에 대해 Lock() 을 걸고 다시 진행. 물론 Lock Manager 가 starve 는 막아준다. 요약해보자. 추가 Lock 을 시도할때 이전에 Lock 했던 자원이 변경될수 있다는것은 엄밀히 말하자면 이 Lock Manger 가 제공하는 Lock 은 '배타적이다' 라고는 할 수 없게 된다.
2. 'writeable' 라는 용어도 약간 다른 의미를 지닌다. 보통 'writeable' 이라 함은 해당 자원을 삭제할 권한도 가지고 있음을 뜻한다. 하지만 위와 같은 경우에서 Lock() 을 했다고 해서 자원을 삭제할 수는 없다. 왜냐하면 다른 누군가가 이미 해당 자원을 Lock 한 뒤에 나의 처리가 끝나기를 대기하고 있을 수 있기 때문이다. 해서 자원의 해제는 조금 다른 관점에서 되어야 한다.
요새는 위와 같은 내용들을 확연히 드러나게 할 수 있는 인터페이스를 고민중이다.
Textcube 1.8.3.1 : Secondary Dominant