2008-10-06 58 views
11

Bất kỳ đề xuất về cách viết các bài kiểm tra đơn vị lặp lại cho mã có thể dễ bị deadlocks và điều kiện chủng tộc?Kiểm tra đơn vị, deadlocks, và điều kiện chủng tộc

Hiện tại tôi đang nghiêng về việc bỏ qua các bài kiểm tra đơn vị và tập trung vào các bài kiểm tra căng thẳng. Vấn đề với điều đó là bạn có thể chạy một bài kiểm tra căng thẳng 5 lần và xem năm kết quả khác nhau. EDIT: Tôi biết nó có thể chỉ là một giấc mơ, nhưng nếu có một cách để kiểm soát các chủ đề cá nhân và làm cho họ thực hiện một lệnh tại một thời điểm sau đó tôi có thể nhận được một nơi nào đó. Chúc May mắn!

+2

* Tuyên bố từ chối trách nhiệm: Tôi làm việc tại Typemock. * Tôi đã xem các nhận xét về Typemock Racer và tôi muốn làm rõ một số điều sau: 1. Racer is ** not ** a "tool test stress" các thuật toán phân tích để khám phá Deadlocks trong mã .NET. Điều này có nghĩa rằng trong trường hợp không có Deadlock được tìm thấy bằng cách sử dụng Racer không có deadlock tồn tại (trừ khi chúng ta có lỗi :)). 2. Chúng tôi đang làm việc chăm chỉ để thêm phát hiện điều kiện Race vào Racer - Trong (gần) các phiên bản tương lai, chúng tôi sẽ phân tích Race Condition nhưng phiên bản hiện tại chỉ tìm thấy bế tắc. 3. Cuối cùng - Racer là trong giai đoạn Alpha của nó có nghĩa là nó miễn phí để tải về và sử dụng b –

Trả lời

3

Hãy xem TypeMock Racer (đó là trong Beta)

chỉnh sửa: thực Alpha

http://www.typemock.com/Typemock_software_development_tools.html

+0

Hãy gọi cho tôi hoài nghi. Tôi đã có điều kiện chủng tộc tôi không thể tái sản xuất ngay cả khi tôi đã tìm ra nguyên nhân gây ra chúng. TypeMock Racer có thể tìm thấy một số nhưng nó chỉ là một thử nghiệm căng thẳng. Đi qua không có nghĩa là họ không phải là bất kỳ điều kiện chủng tộc nào. Tuy nhiên nó có thể hữu ích. –

+0

Đó không thực sự là một "thử nghiệm đơn vị", nhưng nó có thể hữu ích không kém. –

+0

Không, có thể đọc IL và cho bạn biết nếu bạn có một bế tắc và sau đó đưa bạn vào một tình huống. Tôi chỉ có một bản demo, nhưng đó là điều tôi hiểu họ có ý nghĩa khi họ giải thích nó. –

2

Nó thường được dùng để buộc dự kiến ​​ đua điều kiện và sự bế tắc bằng cách sử dụng những thứ như ManualResetEvent để đưa mỗi thread vào trạng thái mong đợi trước khi phát hành nó - tức là lấy thread A để có khóa và chờ tín hiệu ... lấy chuỗi B để yêu cầu khóa, ...

Tuy nhiên - bạn thường có thể viết một thử nghiệm như vậy để điều tra một lỗi nghi ngờ, để chứng minh khi nó được sửa và nó không tái xuất hiện. Bạn thường sẽ thiết kế xung quanh các điều kiện chủng tộc (nhưng kiểm tra chúng tốt nhất là thực dụng).

+0

Cẩn thận - chờ đợi trên một sự kiện gây ra một bộ nhớ cache tuôn ra có thể che giấu một điều kiện chủng tộc. Nó có thể là giá trị sử dụng cho vòng lặp cho sự chậm trễ trong tình huống này. – finnw

+0

Đủ công bằng - Tôi đã nói nhiều hơn về việc chứng minh * hậu quả * của bế tắc, và hiển thị chúng cố định - nhưng điểm được thực hiện. –

1

Không thể nghĩ ra một cách tự động tốt, nhưng gần nhất tôi đã đến là viết một bài kiểm tra đơn vị sẽ 'lộ' một bế tắc bằng cách sử dụng điểm ngắt ngoài bài kiểm tra đơn vị. Tôi chỉ cần thêm một số hướng dẫn về nơi thêm điểm ngắt. Có một số nỗ lực thủ công có liên quan, nhưng với họ, bạn luôn có thể phơi bày lịch trình chuỗi trường hợp xấu hơn của mình.

Có lẽ ai đó đã tìm ra cách tốt để tự động hóa loại chức năng này? Tôi có thể tưởng tượng tự động chạy trình gỡ rối, phá vỡ một luồng tại một dòng cụ thể, cho phép một luồng khác chạy cho đến khi một điều kiện cụ thể, sau đó xác nhận cho thử nghiệm đơn vị.

+0

Vấn đề với điểm phá vỡ là nó thay đổi cách mã hoạt động. Một số hoạt động như sắp xếp lại hướng dẫn và nội tuyến không xảy ra khi trình gỡ lỗi được đính kèm. –

2

Tôi không nghĩ tìm kiếm điều kiện cuộc đua thực sự rơi vào lĩnh vực kiểm tra đơn vị. Nhiều hơn hoặc ít hơn theo định nghĩa, cách duy nhất để kiểm tra các điều kiện chủng tộc là giả ngẫu nhiên. Trừ khi bạn sẵn sàng để đi đến nỗ lực chính thức chứng minh tính chính xác của chiến lược khóa của bạn, bạn sẽ phải làm một số thử nghiệm căng thẳng.

Bạn vẫn cần phải viết các bài kiểm tra đơn vị, để xác minh tính chính xác của các thuật toán, thay vì chiến lược khóa.

Khi mã đa luồng thử nghiệm căng thẳng, bạn sẽ muốn kiểm tra trong điều kiện bạn có một CPU cho mỗi luồng, nơi bạn có nhiều luồng chia sẻ CPU và nơi bạn có nhiều CPU hơn luồng (nếu có thể) .

2

Bạn có thể viết một lớp khóa phát hiện deadlocks tiềm năng, bằng cách xem xét thứ tự của các hoạt động khóa. Chúng tôi làm điều này bằng cách có một bối cảnh thread mà tất cả các khóa đăng ký với khi chúng được mua lại (có thể được thực hiện một tùy chọn chỉ DEBUG).

Ý tưởng là tạo biểu đồ trong đó các nút đại diện cho khóa và cạnh được chỉ đạo giữa A và B có nghĩa là 'khóa A đã được giữ khi khóa B được mua'. Hãy để chương trình của bạn chạy bằng các tải bình thường, sau đó kiểm tra chu trình trong biểu đồ. Chu kỳ nghĩa là có khả năng xảy ra bế tắc ngay cả khi mã của bạn không tấn công.

0

Trước đây tôi đã sử dụng sự chậm trễ nhân tạo trong mã được kích hoạt bởi một số tham số trong yêu cầu. Ví dụ một yêu cầu yêu cầu máy chủ trì hoãn việc ghi giữa hai lần ghi và một để thực hiện chúng mà không bị trì hoãn ở giữa.

A Mark Bessey viết, điều này chỉ hữu ích để tạo repro, không phải để phát hiện sự cố.

Các vấn đề liên quan