Xác định an toàn chủ đề trong các bài kiểm tra đơn vị

Question

Tôi đang viết một ứng dụng đa luồng và đang cố gắng tìm ra cách viết các bài kiểm tra đơn vị cho nó. Tôi nghĩ đó có lẽ là một câu hỏi khác về cách tốt nhất để làm điều đó. Nhưng dù sao tôi có một lớp như dưới đây biết nó không đề an toàn và muốn chứng minh điều đó trong một thử nghiệm đơn vị nhưng không thể làm việc ra làm thế nào để làm điều đó:

public class MyClass 
{ 
    private List<string> MyList = new List<string>(); 

    public void Add(string Data) 
    { 
     MyList.Add(Data); //This is not thread safe!! 
    } 
} 

Answer 1

Chứng minh rằng vấn đề là an toàn chỉ là khó khăn - có thể là vấn đề khó giải quyết. Bạn có thể chỉ ra rằng một điều kiện chủng tộc rất dễ sản xuất, hoặc khó sản xuất. Nhưng không sản xuất một điều kiện chủng tộc không có nghĩa là nó không có ở đó.

Nhưng: cách tiếp cận thông thường của tôi ở đây (nếu tôi có lý do để suy nghĩ một chút mã nên an toàn chỉ, không phải) là xoay vòng nhiều luồng chờ đợi một ManualResetEvent duy nhất. Chủ đề cuối cùng để đến cổng (sử dụng khóa liên động để đếm) có trách nhiệm mở cổng để tất cả các chuỗi truy cập vào hệ thống cùng một lúc (và đã tồn tại). Sau đó, họ thực hiện công việc và kiểm tra các điều kiện thoát hiểm sane. Sau đó, tôi lặp lại quá trình này một số lượng lớn lần. Điều này thường đủ để tái tạo một chuỗi chủ đề bị nghi ngờ và cho thấy rằng nó di chuyển từ "rõ ràng bị hỏng" sang "không bị hỏng theo cách hiển nhiên" (điều này khác biệt đáng kể với "không bị hỏng").

Cũng lưu ý: hầu hết mã không phải là chủ đề an toàn.

Answer 2

an toàn Chủ đề không phải là điều bạn đáng tin cậy có thể kiểm tra bởi vì nó bản chất nó là không xác định. Bạn có thể thử chạy cùng một thao tác vài trăm lần song song trên các luồng khác nhau và xem kết quả có nhất quán ở cuối hay không. Không thực sự tuyệt vời, nhưng tốt hơn là không có gì tôi cho là.

Answer 3

Tôi thường xuyên viết các bài kiểm tra đơn vị để chứng minh rằng một số bộ mã là chuỗi an toàn. Thông thường, tôi viết các xét nghiệm này để đáp ứng với một lỗi tìm thấy trong sản xuất. Trong trường hợp này, mục đích của thử nghiệm là chứng minh rằng lỗi được nhân rộng (kiểm tra thất bại), và mã mới sửa vấn đề luồng (kiểm tra), và sau đó hoạt động như một bài kiểm tra hồi quy cho các bản phát hành trong tương lai.

Hầu hết các bài kiểm tra kiểm tra an toàn chủ đề tôi đã viết thử nghiệm một điều kiện chủng tộc thread, nhưng một số cũng kiểm tra cho deadlocks thread.

Kiểm tra đơn vị chủ động mã là an toàn chủ đề phức tạp hơn một chút. Không phải vì thử nghiệm đơn vị khó viết hơn, nhưng bởi vì bạn phải phân tích vững chắc để xác định (đoán, thực sự,) những gì có thể là chuỗi không an toàn. Nếu phân tích của bạn là chính xác, thì bạn sẽ có thể viết một bài kiểm tra thất bại cho đến khi bạn làm cho chuỗi mã an toàn.

Khi thử nghiệm cho một điều kiện chủ đề chủng tộc, kiểm tra của tôi hầu như luôn luôn theo cùng một khuôn mẫu: (đây là mã giả)

boolean failed = false; 
int iterations = 100; 

// threads interact with some object - either 
Thread thread1 = new Thread(new ThreadStart(delegate() { 
    for (int i=0; i<iterations; i++) { 
    doSomething(); // call unsafe code 
    // check that object is not out of synch due to other thread 
    if (bad()) { 
     failed = true; 
    } 
    } 
}); 
Thread thread2 = new Thread(new ThreadStart(delegate() { 
    for (int i=0; i<iterations; i++) { 
    doSomething(); // call unsafe code 
    // check that object is not out of synch due to other thread 
    if (bad()) { 
     failed = true; 
    } 
    } 
}); 

thread1.start(); 
thread2.start(); 
thread1.join(); 
thread2.join(); 
Assert.IsFalse(failed, "code was thread safe"); 

Answer 4

Tôi đã từ bỏ với đơn vị xét nghiệm để thử và phát hiện các vấn đề luồng. Tôi chỉ sử dụng một thử nghiệm tải hệ thống với một bộ phần cứng đầy đủ, (nếu có phần cứng - thường với các công việc của tôi có, uControllers trên mạng), và một số lượng lớn các máy khách tự động không hợp lý chạy phẳng. Tôi để nó chạy trong một tuần trong khi tôi làm những thứ khác. Vào cuối tuần, tôi lấy tải và kiểm tra những gì còn lại. Nếu nó vẫn hoạt động, không có vật thể nào bị rò rỉ và bộ nhớ không tăng đáng kể, tôi sẽ gửi nó.

Chất lượng như tôi có thể đủ khả năng :)