1/10/2024 0 Comments Deadlock avoidance lock ordering![]() ![]() But in that case you cannot use this gadget, because you do not know all of the locks up front. For example, if the identity of the second lock depends on data protected by the first (say because you are traversing some hierarchy), then you might have to do some grab-release-grab spinning. That is true, but only when you do not know which locks you are trying to grab up front. You can argue that "back off and retry" is sometimes useful. ![]() But once the committee chewed it up, the result is either unimplementable or requires a retry loop. I am guessing it started out as an interesting idea: Let the compiler assign a lock ordering. This appears to be one of the worst things I have ever seen in a C++ standard. (If the "sequence of calls to lock()" in one of these invocations is not "resulting in deadlock", what is, exactly?) However, I am pretty sure this is unimplementable, so I suppose it's not what they meant. Once again, a plain reading of the standard says "no". Std::lock(lock3,lock4) std::lock(lock1,lock2) Std::lock(lock1,lock2) std::lock(lock3,lock4) The only way to do that is with some kind of back-off-and-retry loop. Here again, a plain reading of the standard says "no". Std::lock(lock1, lock2, lock3, lock4) std::lock(lock3, lock4) Great! Maybe the compiler can order my locks for me, which would be kind of neat. Std::lock(lock1, lock2) std::lock(lock2, lock1) Ī plain reading of the standard says "no". Locked by a call to lock() or try_lock().Ĭonsider the following example. end note ] If a call to lock() or try_lock() throwsĪn exception, unlock() shall be called for any argument that had been The specifc algorithm is not specifed to avoid over-constraining [ Note: Aĭeadlock avoidance algorithm such as try-and-back-off must be used, but Not result in deadlock, but is otherwise unspecifed. Try_lock(), or unlock() on each argument. end note ]ĥ Effects: All arguments are locked via a sequence of calls to lock(), Requirements, [ Note: The unique_lock class template meets these I wonder what the standard says it does?Ĭ++11 section 30.4.3, paragraphs (4) and (5):Ĥ Requires: Each template parameter type shall meet the Lockable ![]() Wow, I thought, std::lock sounds interesting. Transfer_money(from_acct, to_acct, amount) Std::lock(lock1, lock2) // avoid deadlock Std::unique_lock lock2(to_acct.mutex, std::defer_lock) I recently encountered some sample C++11 code that looked something like this: std::unique_lock lock1(from_acct.mutex, std::defer_lock) (Note: Much of this is redundant with commentary on Massive CPU load using std::lock (c++11), but I think this topic deserves its own question and answers.) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |