{"id":104949,"date":"2021-03-11T07:00:00","date_gmt":"2021-03-11T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104949"},"modified":"2021-03-12T07:21:30","modified_gmt":"2021-03-12T15:21:30","slug":"20210311-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20210311-00\/?p=104949","title":{"rendered":"Creating other types of synchronization objects that can be used with co_await, part 3: Parallel resumption"},"content":{"rendered":"

Last time, we developed a library for building awaitable synchronization objects<\/a>. I noted that when the coroutines are released, they are resumed in sequence, which means that one coroutine can prevent others from progressing. Let’s resume them in parallel.<\/p>\n

One option is to use Try\u00adSubmit\u00adThreadpool\u00adCallback<\/code> to put the resumption on the thread pool. In the awaitable_state<\/code> class, replace the resume_node<\/code> method with this version:<\/p>\n

        static void CALLBACK resume_node_callback(\r\n            PTP_CALLBACK_INSTANCE, void* context) noexcept\r\n        {\r\n            std::experimental::coroutine_handle<>::\r\n                from_address(context).resume();\r\n        }\r\n\r\n        void resume_node(impl::node_base* node) noexecpt\r\n        {\r\n            if (!TrySubmitThreadpoolCallback(\r\n                resume_node_callback,\r\n                extra_node(*node).handle.address(),\r\n                nullptr))\r\n            {\r\n                std::terminate(); \/\/ fatal\r\n            }\r\n        }\r\n<\/pre>\n
Instead of resuming the handle immediately and synchronously, we submit a callback to the thread pool, and have the callback resume the coroutine.<\/p>\n
This works, but there is a problem if Try\u00adSubmit\u00adThreadpool\u00adCallback<\/code> fails, since we have no way to report an error to the caller. All we can do is terminate the process.<\/p>\n
An alternative is to use the Create\u00adThreadpool\u00adWork<\/code> \/ Submit\u00adThreadpool\u00adWork<\/code> pattern which has the advantage of front-loading all of the error conditions. That way, we can throw a low memory exception at the point of the await<\/code> rather than finding ourselves stuck when it comes time to resume.<\/p>\n
Our node_handle<\/code> now babysits a threadpool work item:<\/p>\n
    struct node_handle : node_base\r\n    {\r\n        PTP_WORK work{};\r\n    };\r\n<\/pre>\n
This member records the work item that we will use to resume the coroutine. It is non-null if the coroutine is on the synchronization object’s wait list. We set this up as part of the suspension:<\/p>\n
        bool await_suspend(\r\n            std::experimental::coroutine_handle<> handle,\r\n            impl::node<extra_await_data>& node)\r\n        {\r\n            auto guard = std::lock_guard(mutex);\r\n            if (parent().claim(node.extra)) return false;\r\n            node.work = check_pointer(\r\n                CreateThreadpoolWork(resume_node_callback,\r\n                    handle.address(), nullptr));<\/span>\r\n            sentinel.append_node(node);\r\n            return true;\r\n        }\r\n<\/pre>\n
When we realize that we need to suspend, we create a work item that will perform the resumption. We can raise a low memory exception at this point, and it will be captured into the caller.<\/p>\n
Resuming the coroutine node consists of submitting the work:<\/p>\n
        void resume_node(impl::node_base* node) noexcept\r\n        {\r\n            SubmitThreadpoolWork(extra_node(*node).work);<\/span>\r\n        }\r\n<\/pre>\n
And we move the work item cleanup into the callback function:<\/p>\n
        static void CALLBACK resume_node_callback(\r\n            PTP_CALLBACK_INSTANCE, void* context, PTP_WORK work<\/span>)\r\n            noexcept\r\n        {\r\n            CloseThreadpoolWork(work);<\/span>\r\n            std::experimental::coroutine_handle<>::\r\n                from_address(context).resume();\r\n        }\r\n\r\n<\/pre>\n
The work can be closed at any time after it is submitted: Closing a submitted work item does not cancel the outstanding work. We don’t want to slow down the resume_list<\/code> method, so we make the work item responsible for its own bookkeeping: That way, the cost is paid by the resuming coroutine rather than the signaling one.<\/p>\n
The other bit of bookkeeping is nulling out the work<\/code> now that it’s been closed.<\/p>\n
        void await_resume(\r\n            impl::node<extra_await_data>& node) noexcept\r\n        {\r\n            node.work = nullptr;<\/span>\r\n        }\r\n<\/pre>\n
And finally, we tweak our abandonment detection:<\/p>\n
        void unlink_node(impl::node_base& node) noexcept\r\n        {\r\n            auto work = extra_node(*node).work;\r\n            if (node.work) {\r\n                CloseThreadpoolWork(work);<\/span>\r\n                auto guard = std::lock_guard(mutex);\r\n                node.next = node.prev->next;\r\n                node.prev = node.next->prev;\r\n            }\r\n        }\r\n<\/pre>\n
There is an additional optimization decision to be made here, which is finding the best place to close the work item. Here’s the diagram again:<\/p>\n
\u00a0<\/div>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Awaiter constructed
\nwork = nullptr;<\/code><\/td>\n<\/tr>\n
\u2193<\/td>\n <\/td>\n\u2193<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
No suspension<\/td>\n <\/td>\nSuspended
\nawait_suspend<\/code>
\nwork = work item;<\/code><\/td>\n		 <\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n\u2193<\/td>\n\u2198\ufe0e<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\nResume
\nresume_node<\/code><\/td>\n		 <\/td>\nAbandoned<\/td>\n<\/tr>\n
 <\/td>\n\u2193<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\nResuming
\nresume_node_callback<\/code>
\nwork closed<\/td>\n		 <\/td>\n<\/tr>\n
 <\/td>\n\u2193<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\nResumed
\nawait_ready<\/code>
\nwork = nullptr;<\/code><\/td>\n		 <\/td>\n<\/tr>\n
\u2193<\/td>\n <\/td>\n\u2193<\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
Awaiter destructed<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The analyses for the no-suspend path and the abandonment path are the same as last time. The extra decision in the center path is deciding when to close the work item. I decided to do it in resume_node_callback<\/code>: I definitely want the work item to be responsible for closing its own work. That avoids adding extra responsibilities to the signaling coroutine, which is only fair because you don’t want to bog down the signaling code with work that wasn’t even its idea! And to reduce code size, I want closing the work item to be done in shared code, which in this case is the thread pool work item callback itself. That same callback is going to be used for all resumptions of all nodes used by any client of this library. If closing the work item had been moved to await_resume<\/code>, then that would get inlined into every coroutine’s resumption code.<\/p>\n
Okay, that was perhaps a deeper dive than you wanted into the subject of creating an awaitable synchronization object. But now that I have this whole thing created, I want to drive it around a bit. We’ll start that  next time<\/a>.<\/p>\n
\n