{"id":103265,"date":"2019-12-25T07:00:00","date_gmt":"2019-12-25T15:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=103265"},"modified":"2019-12-24T20:58:02","modified_gmt":"2019-12-25T04:58:02","slug":"20191225-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20191225-00\/?p=103265","title":{"rendered":"C++ coroutines: The problem of the DispatcherQueue task that runs too soon, part 3"},"content":{"rendered":"

Last time<\/a>, we fixed a race condition in C++\/WinRT’s resume_<\/code>foreground(<\/code>Dispatcher\u00adQueue)<\/code> function when it tries to resume execution on a dispatcher queue. We did this by having the queued task wait until await_<\/code>suspend<\/code> was finished before allowing the coroutine to resume. The hard part was finding a place to put the synchronization object, and we ended up putting it in the queued task’s lambda.<\/p>\n

But it turns out there’s another place we can put it, and it was in front of us the whole time.<\/p>\n

We can put it in the awaiter.<\/p>\n

auto resume_foreground(DispatcherQueue const& dispatcher)\r\n{\r\n  struct awaitable\r\n  {\r\n    DispatcherQueue m_dispatcher;\r\n    bool m_queued = false;\r\n    slim_event ready;<\/span>\r\n\r\n    bool await_ready()\r\n    {\r\n      return false;\r\n    }\r\n\r\n    bool await_suspend(coroutine_handle<> handle)\r\n    {\r\n      bool result = m_dispatcher.TryEnqueue([this,<\/span> handle]\r\n        {\r\n          ready.wait();<\/span>\r\n          handle();\r\n        });\r\n      m_queued = result;\r\n      ready.signal();<\/span>\r\n      return result;\r\n    }\r\n\r\n    bool await_resume()\r\n    {\r\n      return m_queued;\r\n    }\r\n  };\r\n  return awaitable{ dispatcher };\r\n}\r\n<\/pre>\n
The awaiter is destructed when the coroutine resumes, and the coroutine resumes either when the coroutine handle is invoked (which we do in the lambda), or when the await_<\/code>ready<\/code> or await_<\/code>suspend<\/code> methods indicate that the resumption should proceed immediately.<\/p>\n
Therefore, members of the awaiter are good as long as we haven’t done any of those things.<\/p>\n
In the case of a successful Try\u00adEnqueue<\/code>, the await_<\/code>suspend<\/code> is not going to ask for immediate resumption. The resumption will occur when the lambda invokes the handler. But our lambda waits for async_<\/code>suspend<\/code> to signal the event before invoking the handler, so the awaiter is still valid at that point.<\/p>\n
In the case of a failed Try\u00adEnqueue<\/code>, the lambda will never run. Instead, the coroutine resumes after await_<\/code>suspend<\/code> returns with a value of false<\/code>. Prior to the return, the awaiter is still valid, so we can signal the event. (Mind you, there’s nobody listening for the signal.)<\/p>\n
This is a lot simpler than trying to dig the event out of the lambda.<\/p>\n
However, there is still quite a bit of overhead to this plan: While it’s true that the slim_<\/code>event<\/code> runs entirely in user mode in the non-blocking case, it still generates a good number of memory barriers. The slim_<\/code>event::<\/code>signal<\/code> method uses a memory barrier in order to ensure that m_queued<\/code> is made visible to all threads before setting signaled<\/code> to true. If it didn’t do this, then the wait<\/code> function could see that signaled<\/code> is true and run ahead with the wrong value of m_queued<\/code>.<\/p>\n
Furthermore, after the signal<\/code> method updates the signaled<\/code> member, it calls Wake\u00adBy\u00adAddress\u00adAll<\/code>, which will itself erect another memory barrier to make sure it found all the waiters (even if there are none).<\/p>\n
The memory barriers are necessary to ensure that the updated value of m_queued<\/code> that was written by the await_<\/code>suspend<\/code> can be ready by await_<\/code>ready<\/code> in the case that the coroutine continues on the dispatcher thread.<\/p>\n
Next time, we’ll get rid of the memory barriers.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
The storage was right in front of your nose.<\/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-103265","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
The storage was right in front of your nose.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103265","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=103265"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103265\/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=103265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=103265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=103265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}