在Async / Await方法中使用ThreadPool和Task.Wait

Question

I just encountered this code. I immediately started cringing and talking to myself (not nice things). The thing is I don't really understand why and can't reasonably articulate it. It just looks really bad to me - maybe I'm wrong.

public async Task<IHttpActionResult> ProcessAsync()
{
     var userName = Username.LogonName(User.Identity.Name);    
     var user = await _user.GetUserAsync(userName);

     ThreadPool.QueueUserWorkItem((arg) =>
        {
            Task.Run(() => _billing.ProcessAsync(user)).Wait();
        });    
     return Ok();
}

This code looks to me like it's needlessly creating threads with ThreadPool.QueueUserWorkItem and Task.Run . Plus, it looks like it has the potential to deadlock or create serious resource issues when under heavy load. Am I correct?

The _billing.ProcessAsync() method is awaitable (async), so I would expect that a simple "await" keyword would be the right thing to do and not all this other baggage.

Answer 1

I believe Scott is correct with his guess that ThreadPool.QueueUserWorkItem should have been HostingEnvironment.QueueBackgroundWorkItem . The call to Task.Run and Wait , however, are entirely nonsensical - they're pushing work to the thread pool and blocking a thread pool thread on it, when the code is already on the thread pool.

The _billing.ProcessAsync() method is awaitable(async), so I would expect that a simple "await" keyword would be the right thing to do and not all this other baggage.

I strongly agree.

However , this will change the behavior of the action. It will now wait until Billing.ProcessAsync is completed, whereas before it would return early. Note that returning early on ASP.NET is almost always a mistake - I would say any "billing" processing would be even more certainly a mistake. So, replacing this mess with await will make the app more correct, but it will cause the ProcessAsync action to take longer to return to the client.

Answer 2

It's strange, but depending on what the author is trying to achieve, it seems ok to me to queue a work item in the thread pool from inside an async method.

This is not as starting a thread, it's just queueing an action to be done in a ThreadPool's thread when there is a free one. So the async method ( ProcessAsync ) can continue and don't need to care about the result.

The weird thing is the code inside the lambda to be enqueued in the ThreadPool. Not only the Task.Run() (which is superflous and just causes unnecessary overhead), but to call an async method without waiting for it to finish is bad inside a method that should be run by the ThreadPool, because it returns the control flow to the caller when await ing something.

So the ThreadPool eventually thinks this method is finished (and the thread free for the next action in the queue), while actually the method wants to be resumed later.

This may lead to very undefined behaviour . This code may have been working (in certain circumstances), but I would not rely on it and use it as productive code.

(The same goes for calling a not-awaited async method inside Task.Run() , as the Task "thinks" it's finished while the method actually wants to be resumed later).

---

As solution I'd propose to simply await that async method, too:

await _billing.ProcessAsync(user);

But of course without any knowledge about the context of the code snippet I can't guarantee anything. Note that this would change the behaviour: while until now the code did not wait for _billing.ProcessAsync() to finsih, it would now do. So maybe leaving out await and just fire and forget

_billing.ProcessAsync(user);

maybe good enough, too.