교착 상태 및 경쟁 조건의 영향을받을 수있는 코드에 반복 단위 테스트를 작성하는 방법에 대한 제안 사항이 있습니까?단위 테스트, 교착 상태 및 경쟁 조건
지금은 단위 테스트를 건너 뛰고 스트레스 테스트에 중점을두고 있습니다. 문제는 스트레스 테스트를 5 번 실행하고 5 가지 다른 결과를 볼 수 있다는 것입니다.
EDIT : 아마 그저 꿈만 알지만, 개별 스레드를 제어하고 한 번에 하나의 명령을 실행하게하는 방법이 있다면 어딘가로 갈 수 있습니다.
는 TypeMock 레이서 (이 베타 버전의)에서 살펴 보자
편집 : 실제로 알파
http://www.typemock.com/Typemock_software_development_tools.html
회의적으로 전화하십시오. 나는 그들을 일으키는 것이 무엇인지 알았더라도 재현 할 수없는 경쟁 조건을 가지고있다. TypeMock Racer는 일부를 찾을 수도 있지만 스트레스 테스트 일뿐입니다. 합격한다고해서 경쟁 조건이 아닌 것은 아닙니다. 아직도 유용 할 수 있습니다. –
그건 "단위 테스트"가 아니지만 그다지 유용하지는 않습니다. –
아니요, IL을 읽고 교착 상태에 처한 상황을 알려줄 수 있습니다. 방금 데모가 있었는데, 그게 그들이 설명했던대로 데모를 이해하는 것입니다. –
같은 것들을 사용하여 예상 경주 - 조건 교착 상태를 강제하는 것이 가능하다 ManualResetEvent를 사용하여 각 스레드를 해제하기 전에 예상되는 상태로 가져옵니다. 즉 스레드 A가 잠금을 가지고 신호를 기다립니다 ... 스레드 B가 잠금을 요청하게합니다 ...
그러나 일반적으로 의심되는 버그를 조사하고 수정 된 시점을 증명하며 다시 표면을 드러내지 않는 테스트를 작성할 수 있습니다. 일반적으로 경주 조건을 고려하여 설계 할 것입니다 (그러나 실용주의만큼 테스트하십시오).
주의 - 이벤트를 대기하면 경쟁 조건을 숨길 수있는 캐시 플러시가 발생합니다. 이 상황에서 지연을 위해 for-loops를 사용하는 것이 좋습니다. – finnw
충분히 공정한 - 나는 교착 상태의 결과를 증명하는 것에 대해 더 많은 이야기를하고 고정 된 모습을 보여 주었다. –
좋은 자동화 된 방법을 생각할 수는 없지만, 데드락을 '드러내는'단위 테스트를 작성할 때 가장 가까운 것은 단위 테스트 이외에 중단 점을 사용하는 것이 었습니다. 나는 브레이크 포인트를 추가 할 위치에 대한 몇 가지 지침을 추가했다. 수작업으로 인해 약간의 노력이 필요하지만, 그것들을 사용하면 항상 악의적 인 스레드 스케줄을 노출시킬 수 있습니다.
누군가 이러한 유형의 기능을 자동화하는 좋은 방법을 생각해봤을까요? 디버거를 자동으로 실행하고, 특정 라인에서 하나의 스레드를 깨고, 특정 조건까지 다른 스레드를 실행시킨 다음 단위 테스트를 수행한다고 상상할 수 있습니다.
중단 점의 문제점은 코드가 작동하는 방식을 변경한다는 것입니다. 디버거가 연결될 때 명령어 순서 변경 및 인라인과 같은 일부 활동은 발생하지 않습니다. –
경쟁 조건이 실제로 단위 테스트의 영역으로 떨어지는 것은 생각하지 않습니다. 더 많거나 적게 정의에 의해 경쟁 조건을 테스트하는 유일한 방법은 무작위 적입니다. 공식적으로 잠금 전략의 정확성을 입증하려는 노력에 기꺼이 나서지 않는다면, 스트레스 테스트를해야 할 것입니다.
잠금 전략이 아닌 알고리즘의 정확성을 확인하기 위해 단위 테스트를 작성해야합니다.
멀티 스레드 코드를 스트레스 테스트 할 때 스레드 당 CPU가 하나이고 CPU를 공유하는 여러 스레드가 있고 가능한 경우 스레드보다 CPU가 많은 곳에서 테스트해야합니다. .
잠금 조작의 순서를 보면서 잠재적 인 교착 상태를 감지하는 잠금 클래스를 작성할 수 있습니다. 우리는 모든 잠금이 획득 될 때 등록되는 스레드 컨텍스트를 가짐으로써이를 수행합니다 (DEBUG 옵션 만 가능).
아이디어는 노드가 자물쇠를 나타내고 A와 B 사이의 방향이있는 가장자리가 '자물쇠 B가 획득 될 때 잠김 A가 유지되고 있음'을 의미하는 그래프를 만드는 것입니다. 정상적인 부하를 사용하여 프로그램을 실행 한 다음 그래프에서주기를 확인하십시오. 사이클은 코드가 충돌하지 않아도 교착 상태가 발생할 수 있음을 의미합니다.
이전에 요청의 일부 매개 변수에 의해 트리거되는 인공 지연이 코드에서 사용되었습니다. 예를 들어 하나의 요청은 두 개의 쓰기 사이에 쓰기를 지연하도록 서버에 지시하고 그 사이에 지연없이 쓰기를 수행하도록 지시합니다.
Mark Bessey는이 문제가 repro를 만드는 데 유용하며 문제를 발견하는 데 유용하지는 않습니다.
Corensic Jinx을 사용해 보셨습니까?
* 면책 조항 : Typemock에서 근무 * Typemock Racer에 대한 의견을 보았으며 몇 가지를 명확히하고자합니다. 1. Racer는 ** 정적이지 않은 동적 테스트 도구입니다 ** 분석 알고리즘을 사용하여 .NET 코드의 교착 상태 (Deadlocks)를 발견합니다. 즉, Racer를 사용하여 교착 상태가 발견되지 않는 경우 교착 상태가 발생하지 않습니다 (버그가없는 한 :)). 2. 우리는 경주 상태 발견을 Racer에 추가하기 위해 열심히 노력하고 있습니다. - (가까운) 미래 버전에서는 경주 상태 분석이 있지만 현재 버전은 교착 상태 만 찾습니다. 3. 마침내 - Racer는 무료로 다운로드하여 사용할 수 있음을 의미하는 알파 단계입니다. –