{"id":104901,"date":"2021-02-24T07:00:00","date_gmt":"2021-02-24T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104901"},"modified":"2024-04-16T16:00:35","modified_gmt":"2024-04-16T23:00:35","slug":"20210224-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20210224-00\/?p=104901","title":{"rendered":"What is so special about the Application STA?"},"content":{"rendered":"

Windows 8 introduced a new COM threading model which is a variation of the single-threaded apartment (STA). It’s called the Application STA<\/i>.<\/p>\n

The Application STA is a single-threaded apartment, but with the additional restriction that it cannot be re-entered. Consider the following timeline, with time proceeding from top to bottom:<\/p>\n\n\n\n\n\n\n
Thread 1<\/th>\n\u00a0<\/td>\nThread 2
\n(normal STA)<\/th>\n		\u00a0<\/td>\nThread 3<\/th>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nCall thread 3<\/td>\n\u2192<\/td>\nStart operation A<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\n(waiting)<\/td>\n\u00a0<\/td>\n(working)<\/td>\n<\/tr>\n
Call thread 2<\/td>\n\u2192<\/td>\nStart operation B<\/td>\n\u00a0<\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

We have three threads, call them Threads 1, 2, and 3. Thread 2 makes a call to Thread 3 and waits for a response. While Thread 2 is waiting, Thread 1 makes a call into Thread 2. This causes Thread 2 to become re-entered, and that’s a tricky situation.<\/p>\n

If the second call is to perform some operation unrelated to the first call, then you’re probably going to be okay. But suppose the second call is to perform an operation on the same object that the first call is working on. In that case, the first call will have its object modified out from under it.<\/p>\n

void FrobAllWidgets()\r\n{\r\n  for (auto&& widget : m_widgets) {\r\n    widget.Frob(); \/\/ calls to thread 3\r\n  }\r\n}\r\n\r\nvoid AddWidget(Widget const& widget)\r\n{\r\n  m_widgets.push_back(widget);\r\n}\r\n<\/pre>\n
Suppose Thread 2 is doing a Frob\u00adAll\u00adWidgets<\/code>, and the call to widget.Frob();<\/code> results in a call to Thread 3.<\/p>\n
While one of those calls is in progress, Thread 2 is just sitting around waiting for the call to complete.<\/p>\n
And just at that moment, Thread 1 comes in and adds another widget.<\/p>\n
This mutates the vector of widgets, causing the for<\/code> loop in Frob\u00adAll\u00adWidgets<\/code> to go haywire because the vector was resized, causing all the iterators to become invalid.<\/p>\n
You might try to fix this by adding a critical section:<\/p>\n
wil::critical_section m_cs;<\/span>\r\n\r\nvoid FrobAllWidgets()\r\n{\r\n  auto guard = m_cs.lock();<\/span>\r\n  for (auto&& widget : m_widgets) {\r\n    widget.Frob(); \/\/ calls to thread 3\r\n  }\r\n}\r\n\r\nvoid AddWidget(Widget const& widget)\r\n{\r\n  auto guard = m_cs.lock();<\/span>\r\n  m_widgets.push_back(widget);\r\n}\r\n<\/pre>\n
You think you fixed it, but in fact nothing has changed. Critical sections support recursive acquisition, so what happens is that the re-entrant call to Add\u00adWidget<\/code> tries to acquire the critical section, and it succeeds<\/i>, because the owner is the same thread.<\/p>\n
Okay, so switch to something that does not support recursive acquisition, like a shared reader-writer lock.<\/p>\n
wil::srwlock m_srw;<\/span>\r\n\r\nvoid FrobAllWidgets()\r\n{\r\n  auto guard = m_srw.lock_shared();<\/span>\r\n  for (auto&& widget : m_widgets) {\r\n    widget.Frob(); \/\/ calls to thread 3\r\n  }\r\n}\r\n\r\nvoid AddWidget(Widget const& widget)\r\n{\r\n  auto guard = m_srw.lock_exclusive();<\/span>\r\n  m_widgets.push_back(widget);\r\n}\r\n<\/pre>\n
Well, at least this time there’s no crash. Instead the call hangs, because the re-entrant call to to Add\u00adWidget<\/code> tries to acquire the exclusive lock, but it cannot because of the existing call to Frob\u00adAll\u00adWidgets<\/code>. And that existing call cannot complete until Add\u00adWidgets<\/code> completes, because Add\u00adWidgets<\/code> is running on the same stack.<\/p>\n\n\n\n\n\n\n\n
FrobAllWidgets<\/td>\n<\/tr>\n
\u21b3 Widget::Frob<\/td>\n<\/tr>\n
\u21b3 WaitForFrobToFinish<\/td>\n<\/tr>\n
\u21b3 ReceiveInboundCall<\/td>\n<\/tr>\n
\u21b3 AddWidget<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Add\u00adWidget<\/code> is running on the same stack, so Frob\u00adAll\u00adWidgets<\/code> cannot return until the stack unwinds, which means that Add\u00adWidget<\/code> needs to return, but it can’t.<\/p>\n
The Application STA tries to address this problem by blocking re-entrancy. The diagram now looks like this:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Thread 1<\/th>\n\u00a0<\/td>\nThread 2
\n(application STA)<\/th>\n		\u00a0<\/td>\nThread 3<\/th>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\nCall thread 3<\/td>\n\u2192<\/td>\nStart operation A<\/td>\n<\/tr>\n
 <\/td>\n\u00a0<\/td>\n(waiting)<\/td>\n\u00a0<\/td>\n(working)<\/td>\n<\/tr>\n
Call thread 2<\/td>\n\u21b4<\/td>\n <\/td>\n\u00a0<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n\u2193<\/td>\n <\/td>\n\u00a0<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n\u2193<\/td>\n <\/td>\n\u2190<\/td>\nFinished<\/td>\n<\/tr>\n
 <\/td>\n\u2193<\/td>\nFinish<\/td>\n\u00a0<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n\u21b3<\/td>\nOperation B starts<\/td>\n\u00a0<\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
When Thread 1 makes a call into the Application STA while the Application STA is waiting for a response from Thread 3, the call is not allowed to proceed, because that would result in re-entrancy. The call from Thread 1 is placed on hold until Thread 2 is no longer waiting for an outbound call to complete. Once Thread 2 returns to a normal state, it can receive inbound calls again.<\/p>\n
You can detect that you are running in an Application STA by calling Co\u00adGet\u00adApartment\u00adType<\/code> and checking for an apartment type of STA and an apartment type qualifier of APPLICATION_STA.<\/p>\n
Next time, we’ll look at another quirk of the Application STA.<\/p>\n
Bonus chatter<\/b>: I forgot to include the Application STA in my  list of possible results from Co\u00adGet\u00adApartment\u00adType<\/code><\/a>, so I’ve retroactively updated it.<\/p>\n","protected":false},"excerpt":{"rendered":"
Basically, it blocks re-entrancy.<\/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-104901","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Basically, it blocks re-entrancy.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104901","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=104901"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104901\/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=104901"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=104901"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=104901"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}