{"id":109697,"date":"2024-04-23T07:00:00","date_gmt":"2024-04-23T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109697"},"modified":"2024-04-23T09:39:02","modified_gmt":"2024-04-23T16:39:02","slug":"20240423-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240423-00\/?p=109697","title":{"rendered":"Adding state to the update notification pattern, part 5"},"content":{"rendered":"

We’ve been looking at the problem of a stateful but coalescing update notification<\/a>, where multiple requests for work can arrive, and your only requirement is that you send a notification for the last one.<\/p>\n

This time, we’ll apply the trick of using a counter to record who is doing the work on behalf of the most recent change<\/a>. Here’s our first attempt:<\/p>\n

class EditControl\r\n{\r\n    \u27e6 ... existing class members ... \u27e7\r\n\r\n    unsigned m_latestId;<\/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    co_await winrt::resume_background();\r\n\r\n    auto id = ++m_latestId;<\/span>\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    }\r\n\r\n    co_await winrt::resume_foreground(Dispatcher());\r\n\r\n    if (id != m_latestId) co_return;<\/span>\r\n\r\n    SetAutocomplete(matches);\r\n}\r\n<\/pre>\n
Just before we set the results, we check if the m_latestId<\/code> has changed since when we started. If so, then our calculations are stale, and we abandon the operation. Otherwise, we proceed with the results. And we use an unsigned integer for the change counter to avoid undefined behavior on signed overflow.<\/p>\n
There is still a problem here: We hop to a background thread before<\/i> increment the counter. This means that the counter is not necessarily assigned sequentially to each call to TextChanged<\/code>. Suppose the m_latestId<\/code> is initially 0.<\/p>\n\n\n\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)<\/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 1)<\/td>\n<\/tr>\n
\u00a0<\/td>\nid = m_latestId;<\/tt> (id is 2)
\ncalculate matches for “Bob”
\nresume_foreground()<\/tt><\/td>\n		\u00a0<\/td>\n<\/tr>\n
(Bob’s task)
\nif (2 == m_latestId) (true)<\/tt>
\nSetAutocomplete(bob's matches)<\/tt>
\n(Bob’s task completes)<\/td>\n		\u00a0<\/td>\ncalculate matches for “Alice”<\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\nresume_foreground()<\/tt><\/td>\n<\/tr>\n
(Alice’s task)
\nif (1 == m_latestId) (false)<\/tt>
\n(Alice’s task completes)<\/td>\n		\u00a0<\/td>\n\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
We incremented the change counter after<\/i> hopping to the background thread, which means that it happens after we have lost control over the ordering of the work. We have to update the change counter from the UI thread so that the counter values correspond to the order in which the calls arrived, not the order in which the work began.<\/p>\n
The result of this fix is this:<\/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;<\/span>\r\n\r\n    co_await winrt::resume_background();\r\n\r\n    std::vector<std::string> matches = FindMatches(text);\r\n\r\n    co_await winrt::resume_foreground(Dispatcher());\r\n\r\n    if (id != m_latestId) co_return;\r\n\r\n    SetAutocomplete(matches);\r\n}\r\n<\/pre>\n
This approach works, but it is a bit wasteful: If there are multiple changes in rapid succession, we do the work of finding matches for every text change, and throw away all but the last one.<\/p>\n
Next time, we’ll work toward making this more efficient.<\/p>\n","protected":false},"excerpt":{"rendered":"
Using a change counter.<\/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-109697","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Using a change counter.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109697","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=109697"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109697\/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=109697"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=109697"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=109697"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}