winrt::fire_and_forget DoSomething()\r\n{\r\n auto guard = std::lock_guard(m_mutex);\r\n\r\n step1();\r\n\r\n \/\/ All co_awaits must be under an anti-lock.\r\n int cost = [&] {\r\n auto anti_guard = anti_lock(m_mutex);\r\n return co_await GetCostAsync();\r\n }();\r\n\r\n step2(cost);\r\n}\r\n<\/pre>\nFor extra safety, you might require that the anti-lock be given the lock guard that it is counteracting.<\/p>\n
template<typename Guard>\r\nstruct anti_lock\r\n{\r\n using mutex_type = typename Guard::mutex_type;\r\n\r\n anti_lock() = default;\r\n\r\n explicit anti_lock(Guard& guard)\r\n : m_mutex(guard.mutex())\r\n if (m_mutex) m_mutex->unlock();\r\n }\r\n\r\nprivate:\r\n struct anti_lock_deleter {\r\n void operator()(mutex_type* mutex) { m_mutex->lock(); }\r\n };\r\n\r\n std::unique_ptr<mutex_type, anti_lock_deleter> m_mutex;\r\n};\r\n<\/pre>\nBeing given the lock guard means that we can also make it so that the anti-lock of a non-owning guard is a non-owning anti-lock. The negative of zero is zero.<\/p>\n
Being given the lock guard also makes it slightly more noticeable to the caller that the anti-lock might mess with the lock state.<\/p>\n
Now, an anti-lock sounds weird, but you could very well be using it without realizing it: std::condition_variable<\/code>s are secretly anti-locks. They enter with the lock held, then drop the lock while blocked, then reacquire the lock when unblocked.<\/p>\nHere’s another scenario where you may want to use an anti-lock:<\/p>\n
void DoSomething()\r\n{\r\n \/\/ Hold the lock while we check m_nextQuery\r\n std::unique_lock lock(m_mutex);\r\n while (auto query = std::exchange(m_nextQuery, nullptr)) {\r\n \/\/ Drop the lock while we do work\r\n anti_lock anti(lock);\r\n refresh_from_query(query);\r\n \/\/ Reacquire the lock before rechecking m_nextQuery\r\n }\r\n}\r\n<\/pre>\nYou need to hold the mutex while checking if there is a new query (because that mutex protects the code that sets the new query), but you can drop the mutex while you process the query.<\/p>\n
One downside of the anti-lock is that if you have an early return, the mutex is re-locked (when the anti-lock destructs) and then unlocked (when the outer guard destructs). This is hard to fix because there’s no guarantee that the outer guard is going to destruct when the anti-lock destructs:<\/p>\n
void DoSomething()\r\n{\r\n \/\/ Hold the lock while we check m_nextQuery\r\n std::unique_lock lock(m_mutex);\r\n while (auto query = std::exchange(m_nextQuery, nullptr)) {\r\n try {<\/span>\r\n \/\/ Drop the lock while we do work\r\n anti_lock anti(lock);\r\n refresh_from_query(query);\r\n \/\/ Reacquire the lock before rechecking m_nextQuery\r\n } CATCH_LOG(); \/\/ log refresh failures but don't stop<\/span>\r\n }\r\n}\r\n<\/pre>\nIf you can live with this suboptimal behavior (which presumably is infrequent), the anti-lock is pretty handy.<\/p>\n
Bonus chatter<\/b>: The anti-lock does require you to know for sure that the lock is held exactly once. If it’s not held at all, then your anti-lock is unlocking a mutex that isn’t even locked, which is not allowed. And if it’s held twice (allowed by mutex classes such as std::shared_mutex<\/code> and std::recursive_mutex<\/code>), then your anti-lock only counteracts one of the locks, leave the other lock still active.<\/p>\nAnd of course anti-locks complicate lock analysis. If you use an anti-lock to counteract a lock held by the caller, then this invalidates the assumption that holding a lock across a function call protects the state guarded by the lock.<\/p>\n","protected":false},"excerpt":{"rendered":"
It’s not to prevent locking, but rather to counteract a lock.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-110129","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
It’s not to prevent locking, but rather to counteract a lock.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110129","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=110129"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110129\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=110129"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110129"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110129"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}