Tại sao tôi không thể kiểm tra xem một mutex có bị khóa không?

C ++ 14 dường như đã bỏ qua một cơ chế để kiểm tra xem có std::mutexbị khóa hay không. Xem câu hỏi SO này:

https://stackoverflow.com/questions/21892934/how-to-assert-if-a-stdmutex-is-locked

Có một số cách xung quanh điều này, ví dụ bằng cách sử dụng;

std::mutex::try_lock()
std::unique_lock::owns_lock()

Nhưng cả hai đều không phải là giải pháp đặc biệt thỏa mãn.

try_lock()được phép trả lại âm tính giả và có hành vi không xác định nếu luồng hiện tại đã khóa mutex. Nó cũng có tác dụng phụ. owns_lock()yêu cầu xây dựng unique_locktrên đầu trang của bản gốc std::mutex.

Rõ ràng là tôi có thể tự lăn, nhưng tôi muốn hiểu các động lực cho giao diện hiện tại.

Khả năng kiểm tra trạng thái của một mutex (ví dụ std::mutex::is_locked()) dường như không phải là một yêu cầu bí truyền đối với tôi, vì vậy tôi nghi ngờ Ủy ban Tiêu chuẩn cố tình bỏ qua tính năng này thay vì là một sự giám sát.

Tại sao?

Chỉnh sửa: Ok vì vậy có thể trường hợp sử dụng này không phổ biến như tôi mong đợi, vì vậy tôi sẽ minh họa kịch bản cụ thể của mình. Tôi có một thuật toán học máy được phân phối trên nhiều luồng. Mỗi luồng hoạt động không đồng bộ và trở về nhóm chính sau khi hoàn thành vấn đề tối ưu hóa.

Sau đó nó khóa một mutex master. Sau đó, chủ đề phải chọn một bố mẹ mới để đột biến con cái, nhưng chỉ có thể chọn từ bố mẹ hiện không có con cái đang được tối ưu hóa bởi các chủ đề khác. Do đó, tôi cần phải thực hiện tìm kiếm để tìm cha mẹ hiện không bị khóa bởi một luồng khác. Không có rủi ro về tình trạng của mutex thay đổi trong quá trình tìm kiếm, vì mutex chủ đề bị khóa. Rõ ràng là có các giải pháp khác (hiện tôi đang sử dụng cờ boolean) nhưng tôi nghĩ rằng mutex cung cấp một giải pháp hợp lý cho vấn đề này, vì nó tồn tại cho mục đích đồng bộ hóa giữa các luồng.

Tôi có thể thấy ít nhất hai vấn đề nghiêm trọng với hoạt động được đề xuất.

Cái đầu tiên đã được đề cập trong một bình luận của @ gnasher729 :

Bạn thực sự không thể kiểm tra một cách hợp lý liệu một mutex có bị khóa hay không, bởi vì một nano giây sau khi kiểm tra nó có thể được mở khóa hoặc khóa hay không. Vì vậy, nếu bạn đã viết if (mutex_is_locked ()) …thì mutex_is_lockedcó thể trả về kết quả chính xác, nhưng vào thời điểm ifthực thi, nó đã sai.

Cách duy nhất để chắc chắn rằng hiện tại, hiện đang bị khóa tài sản của một mutex không thay đổi là, hãy tự khóa nó.

Vấn đề thứ hai tôi thấy là trừ khi bạn khóa mutex, luồng của bạn không đồng bộ hóa với luồng đã khóa mutex trước đó. Do đó, thậm chí còn không được định nghĩa rõ ràng để nói về những điều trước đây và trước khi nói về vấn đề này và liệu mutex có bị khóa hay không là cách hỏi liệu con mèo của Schrödiger có còn sống mà không cố mở hộp không.

Nếu tôi hiểu chính xác, thì cả hai vấn đề sẽ được khắc phục trong trường hợp cụ thể của bạn nhờ vào mutex chính bị khóa. Nhưng đây không phải là trường hợp đặc biệt phổ biến đối với tôi nên tôi nghĩ rằng ủy ban đã làm đúng bằng cách không thêm một chức năng có thể hữu ích trong các tình huống rất đặc biệt và gây thiệt hại cho tất cả những người khác. (Theo tinh thần của: Làm cho giao diện dễ sử dụng một cách chính xác và khó sử dụng không chính xác.

Và nếu tôi có thể nói, tôi nghĩ rằng thiết lập mà bạn hiện có không phải là thanh lịch nhất và có thể được cấu trúc lại để tránh vấn đề hoàn toàn. Ví dụ, thay vì luồng chính kiểm tra tất cả các bậc cha mẹ tiềm năng cho một cha mẹ hiện không bị khóa, tại sao không duy trì hàng đợi cha mẹ sẵn sàng? Nếu một chủ đề muốn tối ưu hóa một chủ đề khác, nó sẽ bật cái tiếp theo ra khỏi hàng đợi và ngay khi nó có cha mẹ mới, nó sẽ thêm chúng vào hàng đợi. Theo cách đó, bạn thậm chí không cần chủ đề chính như một điều phối viên.

Có vẻ như bạn đang sử dụng các mutexes thứ cấp không để khóa quyền truy cập vào một vấn đề tối ưu hóa, nhưng để xác định xem một vấn đề tối ưu hóa có được tối ưu hóa ngay bây giờ hay không.

Điều đó là hoàn toàn không cần thiết. Tôi có một danh sách các vấn đề cần tối ưu hóa, một danh sách các vấn đề đang được tối ưu hóa ngay bây giờ và một danh sách các vấn đề đã được tối ưu hóa. (Đừng lấy "danh sách" theo nghĩa đen, hãy hiểu nó là "bất kỳ cấu trúc dữ liệu phù hợp nào).

Các hoạt động thêm một vấn đề mới vào danh sách các vấn đề chưa được tối ưu hóa, hoặc chuyển một vấn đề từ danh sách này sang danh sách tiếp theo, sẽ được thực hiện dưới sự bảo vệ của mutex "master" duy nhất.

Như những người khác đã nói, không có trường hợp sử dụng nào trong trường hợp đột biến có is_lockedlợi ích gì, đó là lý do tại sao chức năng này không tồn tại.

Trường hợp bạn gặp vấn đề rất phổ biến, về cơ bản, đó là những gì các luồng công nhân làm, một trong những, nếu không phải là triển khai phổ biến nhất của các luồng.

Bạn có một kệ với 10 hộp trên đó. Bạn có 4 công nhân làm việc với các hộp này. Làm thế nào để bạn chắc chắn rằng 4 công nhân làm việc trên các hộp khác nhau? Công nhân đầu tiên lấy một cái hộp ra khỏi kệ trước khi họ bắt đầu làm việc với nó. Công nhân thứ hai nhìn thấy 9 hộp trên kệ.

Không có mutex để khóa các hộp, vì vậy việc nhìn thấy trạng thái của mutex tưởng tượng trên hộp là không cần thiết, và lạm dụng một mutex như một boolean là sai. Các mutex khóa kệ.

Ngoài hai lý do được đưa ra trong câu trả lời của 5gon12eder ở trên, tôi muốn nói thêm rằng nó không cần thiết cũng không mong muốn.

Nếu bạn đang giữ một mutex, thì bạn nên biết rằng bạn đang giữ nó! Bạn không cần phải hỏi. Giống như việc sở hữu một khối bộ nhớ hoặc bất kỳ tài nguyên nào khác, bạn nên biết chính xác mình có sở hữu nó hay không và khi nào thì thích hợp để giải phóng / xóa tài nguyên.
Nếu đó không phải là trường hợp, chương trình của bạn được thiết kế tồi và bạn đang gặp rắc rối.

Nếu bạn cần truy cập vào tài nguyên được chia sẻ được bảo vệ bởi mutex và bạn chưa nắm giữ mutex, thì bạn cần phải có được mutex. Không có lựa chọn nào khác, nếu không thì logic chương trình của bạn không đúng.
Bạn có thể thấy việc chặn có thể chấp nhận hoặc không thể chấp nhận được, trong cả hai trường hợp lock()hoặc try_lock()sẽ đưa ra hành vi bạn muốn. Tất cả những gì bạn cần biết, một cách tích cực, và không nghi ngờ gì, là liệu bạn có mua thành công mutex hay không (giá trị trả về try_lockcho bạn biết). Không quan trọng cho dù người khác giữ nó hay bạn có thất bại giả hay không.

Trong mọi trường hợp khác, nói thẳng ra, đó không phải là việc của bạn. Bạn không cần phải biết và bạn không nên biết hoặc đưa ra các giả định (về các vấn đề đồng thời và đồng bộ được đề cập trong câu hỏi khác).

Bạn có thể muốn sử dụng nguyên tử_flag với thứ tự bộ nhớ mặc định. Nó không có các cuộc đua dữ liệu và không bao giờ đưa ra các ngoại lệ như mutex thực hiện với nhiều cuộc gọi mở khóa (và hủy bỏ không kiểm soát được, tôi có thể thêm ...). Ngoài ra, có nguyên tử (ví dụ: nguyên tử [bool] hoặc nguyên tử [int] (với dấu ngoặc tam giác, không phải [])), có các chức năng tốt như tải và so sánh_exchange_strong.

Tôi muốn thêm trường hợp sử dụng cho việc này: Nó sẽ cho phép một chức năng nội bộ để đảm bảo là điều kiện tiên quyết / khẳng định rằng người gọi thực sự đang giữ khóa.

Đối với các lớp có một số hàm nội bộ như vậy và có thể nhiều hàm công khai gọi chúng, có thể đảm bảo rằng ai đó thêm một hàm công khai khác gọi hàm nội bộ thực sự có được khóa.

class SynchronizedClass
{

public:

void publicFunc()
{
  std::lock_guard<std::mutex>(_mutex);

  internalFuncA();
}

// A lot of code

void newPublicFunc()
{
  internalFuncA(); // whops, forgot to acquire the lock
}


private:

void internalFuncA()
{
  assert(_mutex.is_locked_by_this_thread());

  doStuffWithLockedResource();
}

};