Cách tốt nhất để kiểm tra triển khai Mutex?

Question

Cách tốt nhất để kiểm tra việc thực hiện một mutex thực sự là chính xác? (Nó là cần thiết để thực hiện một mutex, tái sử dụng không phải là một lựa chọn khả thi)

Tốt nhất tôi đã đưa ra là có nhiều (N) chủ đề đồng thời lặp đi lặp lại cố gắng để truy cập vào khu vực được bảo vệ (I) lần, trong đó có tác dụng phụ (ví dụ: cập nhật lên toàn cầu) để số lần truy cập + ghi có thể được tính để đảm bảo rằng số lượng cập nhật cho toàn cầu chính xác (N) * (I).

Bất kỳ đề xuất nào khác?

Answer 1

Điều này nhắc tôi về câu hỏi này về FIFO semaphore test. Tóm lại câu trả lời của tôi là:

• Thậm chí nếu bạn có một đặc điểm kỹ thuật, có thể nó không truyền đạt ý định của bạn chính xác
• Bạn có thể chứng minh rằng các thuật toán đáp ứng các đặc điểm kỹ thuật, nhưng không phải là mã (D.Knuth)
• thử nghiệm cho thấy chỉ sự hiện diện của lỗi, không vắng mặt của họ (Dijkstra)

Vì vậy, đề xuất của bạn có vẻ hợp lý tốt nhất để làm. Nếu bạn muốn tăng sự tự tin của mình, hãy sử dụng fuzzing để ngẫu nhiên lập lịch và nhập.

Answer 2

Bằng chứng chính thức tốt hơn thử nghiệm cho loại điều này.

Thử nghiệm sẽ cho bạn thấy rằng - miễn là bạn không may mắn - tất cả đều hiệu quả. Nhưng một thử nghiệm là một công cụ cùn; nó có thể không thực hiện đúng trình tự chính xác để gây ra lỗi.

Quá khó để kiểm tra mọi trình tự hoạt động có thể có trong phần cứng để đảm bảo mutex của bạn hoạt động trong mọi trường hợp.

Thử nghiệm không phải không có giá trị; nó cho thấy bạn không tạo ra bất kỳ lỗi mã hóa rõ ràng nào. Nhưng bạn thực sự cần kiểm tra mã chính thức hơn để chứng minh rằng nó thực hiện đúng những điều đúng vào đúng thời điểm sao cho một khách hàng sẽ nắm bắt nguyên tắc khóa tài nguyên cần thiết cho mutex phù hợp. Trong nhiều nền tảng, có những hướng dẫn đặc biệt để thực hiện điều này và nếu bạn đang sử dụng một trong những nền tảng đó, bạn có cơ hội chiến đấu để làm đúng.

Tương tự, bạn phải chứng minh rằng bản phát hành là nguyên tử.

Answer 3

Với một cái gì đó giống như một mutex, chúng tôi trở lại quy tắc cũ rằng thử nghiệm chỉ có thể chứng minh sự hiện diện của các lỗi, chứ không phải sự vắng mặt. Một năm thử nghiệm có thể sẽ cho bạn biết ít hơn chỉ đơn giản là đặt mã lên để kiểm tra, và hỏi xem có ai gặp vấn đề với nó không.

Answer 4

Nếu công cụ kiểm tra không hoạt động cho bạn, hãy thử với thử nghiệm. Hãy chắc chắn kiểm tra tất cả các trường hợp sử dụng có thể. Tìm hiểu chính xác điều này sẽ được sử dụng như thế nào, ai sẽ sử dụng nó và, một lần nữa, nó sẽ được sử dụng như thế nào. Khi bạn đi thử nghiệm tuyến đường chắc chắn để chạy mỗi thử nghiệm cho mỗi kịch bản một tấn lần (hàng triệu, hàng tỷ, như nhiều như bạn có thể có thể nhận được trong với thời gian thử nghiệm bạn có).

Cố gắng ngẫu nhiên vì ngẫu nhiên sẽ cho bạn cơ hội tốt nhất để bao quát tất cả các tình huống trong một số lượng kiểm tra giới hạn. Hãy chắc chắn sử dụng dữ liệu sẽ được sử dụng và dữ liệu có thể không được sử dụng nhưng có thể được sử dụng và đảm bảo dữ liệu không làm hỏng ổ khóa.

BTW, trừ khi bạn biết rất nhiều về toán học và các phương pháp chính thức, bạn sẽ không có cơ hội thực sự đưa ra bằng chứng.

Answer 5

Tôi với mọi người khác rằng điều này là vô cùng khó khăn để chứng minh một cách thuyết phục, tôi không có ý tưởng làm thế nào để làm điều đó - không hữu ích tôi biết!

Khi bạn nói thực hiện một mutex và tái sử dụng không phải là một lựa chọn, đó là vì lý do kỹ thuật như không có triển khai Mutex trên nền tảng/hệ điều hành mà bạn đang sử dụng hoặc một số lý do khác? Là gói một số hình thức cấp độ hệ điều hành 'khóa' và gọi nó là thực hiện Mutex của bạn một lựa chọn, ví dụ như CriticalSection trên windoze, posix Điều kiện biến? Nếu bạn có thể bọc khóa hệ điều hành ở mức thấp hơn thì cơ hội nhận được khóa của bạn sẽ cao hơn nhiều.

Trong trường hợp bạn chưa làm như vậy hãy đọc và đọc Herb Sutter's Effective Concurrency bài viết. Nên có một số thứ trong những thứ đáng giá này cho bạn.

Dù sao, một số điều cần xem xét trong các thử nghiệm của bạn:

• Nếu mutex của bạn là đệ quy (tức là có thể cùng một sợi khóa nó nhiều lần) sau đó đảm bảo bạn làm một số xét nghiệm tính tham khảo.
• Với biến toàn cầu của bạn, bạn sửa đổi nó sẽ là tốt nhất nếu đây là một biến thể không thể được viết thành nguyên tử. Ví dụ: nếu bạn là trên nền tảng 8 bit thì hãy sử dụng biến số bit 16 hoặc 32 bit yêu cầu nhiều hướng dẫn lắp ráp để viết.
• Kiểm tra kỹ danh sách lắp ráp. Tùy thuộc vào nền tảng phần cứng mặc dù lắp ráp không dịch trực tiếp đến cách mã có thể được tối ưu hóa ...
• Nhận người khác, người không viết mã, cũng viết một số kiểm tra.
• thử nghiệm trên nhiều máy khác nhau với thông số kỹ thuật khác nhau như bạn có thể (giả định rằng đây là 'mục đích chung' và không cho một thiết lập phần cứng cụ thể)

Chúc may mắn!