{"id":8933,"date":"2011-12-09T07:00:00","date_gmt":"2011-12-09T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2011\/12\/09\/sure-im-supposed-to-pass-wt_executelongfunction-if-my-function-takes-a-long-time-but-how-long-is-long\/"},"modified":"2011-12-09T07:00:00","modified_gmt":"2011-12-09T07:00:00","slug":"sure-im-supposed-to-pass-wt_executelongfunction-if-my-function-takes-a-long-time-but-how-long-is-long","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20111209-00\/?p=8933","title":{"rendered":"Sure, I'm supposed to pass WT_EXECUTELONGFUNCTION if my function takes a long time, but how long is long?"},"content":{"rendered":"

A customer contacted me to tell a story and ask a question. The customer discovered that in their code base, all calls to Queue­User­Work­Item<\/code> passed the WT_EXECUTE­LONG­FUNCTION<\/code> flag, regardless of whether the function actually took a long time or not. Their program creates a large number of work items at startup, and the result of passing WT_EXECUTE­LONG­FUNCTION<\/code> for all of them was that the thread pool created a new thread for each queued work item, resulting in a bloated thread pool that thrashed the CPU.\n When he asked the other people on his team why they were passing the WT_EXECUTE­LONG­FUNCTION<\/code> flag unconditionally, they pointed to this article from 2005 on the importance of passing the WT_EXECUTE­LONG­FUNCTION<\/code> flag to the Queue­User­Work­Item<\/code> function<\/a>.\n As I’ve mentioned before, Good advice comes with a rationale so you can tell when it becomes bad advice<\/a>, but the people who applied my advice didn’t understand the rationale and merely concluded, “It is important always to pass the WT_EXECUTE­LONG­FUNCTION<\/code> flag!”\n The WT_EXECUTE­LONG­FUNCTION<\/code> flag is two-edged. If you pass the flag when queueing a task, then the thread pool will more aggressively create a new thread when that task is running. The upside is that other tasks don’t get stuck waiting for your long-running task. The downside is that this creates more threads. And if you set the flag for all<\/i> of your tasks, then you don’t really have a thread pool at all, since you basically told the thread pool, “Run every task on its own thread, stat!”\n But this raises the question of “How long is long?” How long does a task need to run before you declare it a long-running task?\n There is no magic number here.\n The definition of a long-running task depends on the nature of your application. Let’s consider, for concreteness, a task that takes one second. If this task is not marked as a long-running task, then the thread pool will wait for it to complete rather than creating a new thread. What are the consequences for your application of the thread pool choosing to wait for one second rather than creating a new thread? If your application doesn’t generate tasks at such a high rate that a one-second pause would be a significant problem, then it’s not a long-running task.\n On the other hand, if your application is a service that is handling thousands of requests per second, then waiting for a one-second tasks means that a thousand tasks pile up in the meantime, and that may be enough to push your service to the brink of death<\/a> because it has started falling behind on its processing and may never catch up.<\/p>\n

Which category does your application fall in? That’s for you to determine. <\/p>\n","protected":false},"excerpt":{"rendered":"

A customer contacted me to tell a story and ask a question. The customer discovered that in their code base, all calls to Queue­User­Work­Item passed the WT_EXECUTE­LONG­FUNCTION flag, regardless of whether the function actually took a long time or not. Their program creates a large number of work items at startup, and the result of […]<\/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-8933","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

A customer contacted me to tell a story and ask a question. The customer discovered that in their code base, all calls to Queue­User­Work­Item passed the WT_EXECUTE­LONG­FUNCTION flag, regardless of whether the function actually took a long time or not. Their program creates a large number of work items at startup, and the result of […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/8933","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=8933"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/8933\/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=8933"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=8933"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=8933"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}