{"id":109702,"date":"2024-04-25T07:00:00","date_gmt":"2024-04-25T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109702"},"modified":"2024-04-25T09:32:55","modified_gmt":"2024-04-25T16:32:55","slug":"20240425-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240425-00\/?p=109702","title":{"rendered":"Adding state to the update notification pattern, part 7"},"content":{"rendered":"

Last time, we refined our change counter-based stateful but coalescing update notification<\/a>. This version still relies on a UI thread to do two things: (1) make the final final change counter check and the subsequent callback atomic, and (2) to serialize the callbacks.<\/p>\n

If we don’t have a UI thread, then we open a race condition.<\/p>\n

class EditControl\r\n{\r\n    \u27e6 ... existing class members ... \u27e7\r\n\r\n    std::atomic<unsigned> m_latestId;\r\n};\r\n\r\nwinrt::fire_and_forget\r\nEditControl::TextChanged(std::string text)\r\n{\r\n    auto lifetime = get_strong();\r\n\r\n    auto id = m_latestId.fetch_add(1, std::memory_order_relaxed);\r\n\r\n    co_await winrt::resume_background();\r\n\r\n    if (!IsLatestId(id))) co_return;\r\n\r\n    std::vector<std::string> matches;\r\n    for (auto&& candidate : FindCandidates(text)) {\r\n        if (candidate.Verify()) {\r\n            matches.push_back(candidate.Text());\r\n        }\r\n        if (!IsLatestId(id))) co_return;\r\n    }\r\n\r\n    \/\/ co_await winrt::resume_foreground(Dispatcher());<\/span><\/span>\r\n\r\n    if (!IsLatestId(id))) co_return;\r\n\r\n    SetAutocomplete(matches);\r\n}\r\n<\/pre>\n
Another call to TextChanged<\/code> could happen just before the Set\u00adAutocomplete<\/code>, and its work could race ahead of the first task.<\/p>\n\n\n\n\n\n\n\n\n
UI thread<\/th>\nBackground thread 1<\/th>\nBackground thread 2<\/th>\n<\/tr>\n
TextChanged(\"Bob\")<\/tt>
\nresume_background()<\/tt><\/td>\n		\u00a0<\/td>\n\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n(Bob’s task)
\nid = m_latestId;<\/tt> (id is 1)
\ncalculate matches for “Bob”
\nif (1 == m_latestId) (true)<\/tt><\/td>\n		\u00a0<\/td>\n<\/tr>\n
TextChanged(\"Alice\");<\/tt>
\nresume_background()<\/tt><\/td>\n		\u00a0<\/td>\n\u00a0<\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n(Alice’s task)
\nid = m_latestId;<\/tt> (id is 2)
\ncalculate matches for “Alice”
\nif (2 == m_latestId) (true)<\/tt>
\nSetAutocomplete(alice's matches)<\/tt><\/td>\n<\/tr>\n
\u00a0<\/td>\nSetAutocomplete(bob's matches)<\/tt><\/td>\n\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
One temptation is to fix this by restoring atomicity by adding a lock:<\/p>\n
winrt::fire_and_forget\r\nEditControl::TextChanged(std::string text)\r\n{\r\n    auto lifetime = get_strong();\r\n\r\n    auto id = m_latestId.fetch_add(1, std::memory_order_relaxed);\r\n\r\n    co_await winrt::resume_background();\r\n\r\n    if (!IsLatestId(id))) co_return;\r\n\r\n    std::vector<std::string> matches;\r\n    for (auto&& candidate : FindCandidates(text)) {\r\n        if (candidate.Verify()) {\r\n            matches.push_back(candidate.Text());\r\n        }\r\n        if (!IsLatestId(id))) co_return;\r\n    }\r\n\r\n    auto lock = std::unique_lock(m_mutex);<\/span>\r\n\r\n    if (!IsLatestId(id))) co_return;\r\n\r\n    SetAutocomplete(matches);\r\n}\r\n<\/pre>\n
The good news is that this avoids the race condition. One thing to check is that nothing bad happens if Set\u00adAutocomplete<\/code> itself triggers a recursive call to Text\u00adChanged<\/code>: Since the Set\u00adAutocomplete<\/code> is happening on a background thread, a call to Text\u00adChanged<\/code> would hop to another background thread before eventually blocking on the mutex. Nobody is deadlocked, so we’re okay there.<\/p>\n
But there is a problem if the Text\u00adChange<\/code> calls come in faster than Set\u00adAutocomplete<\/code> can process them. In that case, each Text\u00adChange<\/code> consumes a background thread and blocks on the mutex. There could be a lot of background threads all waiting for their turn to call Set\u00adAutocomplete<\/code>, but not able to make progress because the current active call to Set\u00adAutocomplete<\/code> is taking too long. In the worst case, Set\u00adAutocomplete<\/code> takes so long that you end up consuming all the threads in the threadpool, which tends not to end well.<\/p>\n
Instead of using a mutex, we can use an “async mutex”, where each waiting coroutine just suspends until its turn to enter the protected region. Fairness is not important here, because all but one of the coroutines will bail out when they realize that their change counter doesn’t match, so we can use  simple task sequencer that uses a kernel event.<\/p>\n
class EditControl\r\n{\r\n    \u27e6 ... existing class members ... \u27e7\r\n\r\n    std::atomic<unsigned> m_latestId;\r\n    wil::unique_event m_serializerEvent{ wil::EventOptions::Signaled };<\/span>\r\n};\r\n\r\nwinrt::fire_and_forget\r\nEditControl::TextChanged(std::string text)\r\n{\r\n    auto lifetime = get_strong();\r\n\r\n    auto id = m_latestId.fetch_add(1, std::memory_order_relaxed);\r\n\r\n    co_await winrt::resume_background();\r\n\r\n    if (!IsLatestId(id))) co_return;\r\n\r\n    std::vector<std::string> matches;\r\n    for (auto&& candidate : FindCandidates(text)) {\r\n        if (candidate.Verify()) {\r\n            matches.push_back(candidate.Text());\r\n        }\r\n        if (!IsLatestId(id))) co_return;\r\n    }\r\n\r\n    co_await winrt::resume_on_signal(m_serializerEvent.get());    <\/span>\r\n    auto next = wil::SetEvent_scope_exit(m_serializerEvent.get());<\/span>\r\n\r\n    if (!IsLatestId(id))) co_return;\r\n\r\n    SetAutocomplete(matches);\r\n}\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Going free-threaded.<\/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-109702","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Going free-threaded.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109702","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=109702"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109702\/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=109702"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=109702"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=109702"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}