等待异步方法后的长任务

Question

While the following question is generally applicable to all usage of async/await in C#, it refers to Json.NET. The JsonConvert.DeserializeObjectAsync() method has been marked as obsolete by the development team as it would be difficult to maintain and not of much use since most JSON files are small (Refer this ).

I have some code following this structure:

public async Task<CarObj> GetCarAsync()
{
    string json = await GetJsonStringFromRestEndpoint();
    // At this point, we should already be on a separate thread since we have awaited a long running task.

    // 1 - Running this relatively long task on this thread should be fine since we're already on a new thread than the caller.
    CarObj obj = JsonConvert.DeserializeObject<CarObj>(json);

    // 2 - Would this better for some reason?
    CarObj obj2 = await Task.Run(() => JsonConvert.DeserializeObject<CarObj>(json));
}

Would option 1 or 2 in the code above be the better solution here?

Answer 1

Arguably this is primarily opinion-based. But…

Assuming the library authors are correct, your first option is better. But not for the reason you think.

When the await GetJsonStringFromRestEndpoint() completes, then assuming the GetCarAsync() method was called from a thread with a synchronization context, the call to DeserializeObject<CarObj>(json); will happen on that same thread.

The reason calling the method synchronously isn't a problem isn't because you're on a different thread (you're not), but rather because as the library authors point out, the input data isn't likely to be large enough for there to be any significant performance problem. You can probably parse the entire JSON data and construct your CarObj value in less time than it takes to queue up the thread pool work item, context-switch to that thread, and then context-switch back.

In other words, don't use worker threads to perform computationally inexpensive work.

Answer 2

// At this point, we should already be on a separate thread since we have awaited a long running task.

No, the caller thread is called back (resumed) instead.

But - if this is not your intended behavior - I'd advice to add

 .ConfigureAwait(false);

That would save some synchronization work and afterwards you'll reasonably expect to be in a thread pull thread.