Concurrent and Distributed Desk Checking

ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1303337

 

이 논문은 static analysis라고 할 수 있는 desk checking을 concurrent programming환경에서 어떻게 적용할 수 있는지 설명한다. 주목할 것은 네 가지 역할을 가진 사람이 정의된다. 일단 code를 작성한 program owner, interleaving(the sequence of concurrent events that occurred)을 수행하는 program counter, contention on shared resources을 조장(?)하는 devil's advocate 그리고 결과를 요약하여 기록하는 stenographer가 있게 된다. 기존의 sequential programming기반의 inspection, review와 비교하여 눈여겨 볼 것은 devil's advocate의 역할이다. 이 사람은 concurrent programming기반의 bug pattern을 잘 이해하고 있어야 하며 이러한 지식을 기반으로 공유자원(shared resources)에 대한 thread, process들간의 상호 경쟁(contentions)를 잘 이끌어 낼 수 있어야 한다. 또한 infeasible 한 interleaving은 제거한다.

 

주요 내용들은 인용하면 아래와 같다.

...........

The new concurrent and distributed desk checking technique supports the selection of schedules and execution states to be reviewd.

..........

But in today's world of concurrent and distributed programs, desk checking gives rise to several problems, one of which is nondeterminism.

..........

Naturally, it is not recommended that the devil's advocate and the program owner be the same person.

.........

The devil's advocate guidelines are listed on the understanding of concurent bug patterns.

- Increase contentions on shared resources. Contention on shared variables is required for race conditions to be possible.

- Delay locks so that locks are obtained in different orders.

- while in a critical section

: Force error paths. Sometimes resources are not freed along error paths. More specifically, locks are not freed along error paths.

: Assume that potentially blocked operations are blocked. If this assumption is correct it might reveal a hang in the system.

: Cause signals and interrupts to occur. This might cause a change of control(a jump to a single handler). As a result, a deadlock might occur if a reentry of the critical section is attempted by the single handler code.

- Cover all possible scenarios of waiting on events. All these scenarios should be correctly handled by the implementation. Possible scenarios include:

: Event notification being sent before and after the event is waited on.

: Event notificatoin being sent after the event is checked and before it is waited on in the case that waiting on an event is not atomic.

- Break assumptions that depend on hardware and scheduler as code should not depend on such assumptions.

- Assume that delays are not long enough.

- Assume that the memory model renders changes invisible. Fualts are sometimes the result of misconceptions about variable value visibilities.

 

헉헉 copy&paste 아님... ㅡ.ㅡ;;