Mục đích của việc quay trở lại đang chờ đợi trong C # là gì?

Có kịch bản nào mà phương thức viết như thế này không:

public async Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return await DoAnotherThingAsync();
}

thay vì điều này:

public Task<SomeResult> DoSomethingAsync()
{
    // Some synchronous code might or might not be here... //
    return DoAnotherThingAsync();
}

sẽ có ý nghĩa?

Tại sao sử dụng return awaitcấu trúc khi bạn có thể trực tiếp trở về Task<T>từ DoAnotherThingAsync()lời gọi bên trong ?

Tôi thấy mã với return awaitrất nhiều nơi, tôi nghĩ rằng tôi có thể đã bỏ lỡ một cái gì đó. Nhưng theo tôi hiểu, không sử dụng async / await các từ khóa trong trường hợp này và trực tiếp trả về Nhiệm vụ sẽ tương đương về mặt chức năng. Tại sao thêm chi phí bổ sung của awaitlớp bổ sung ?

Có một trường hợp lén lút khi returntrong phương thức bình thường và return awaittrong asyncphương thức hoạt động khác nhau: khi kết hợp với using(hoặc, nói chung hơn, bất kỳ return awaittrong một trykhối).

Hãy xem xét hai phiên bản của một phương thức:

Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return foo.DoAnotherThingAsync();
    }
}

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

Phương pháp đầu tiên sẽ Dispose()là Foođối tượng ngay sau khi DoAnotherThingAsync()trở về phương pháp, đó là khả năng rất lâu trước khi nó thực sự hoàn tất. Điều này có nghĩa là phiên bản đầu tiên có thể có lỗi (vì Foođược xử lý quá sớm), trong khi phiên bản thứ hai sẽ hoạt động tốt.

Nếu bạn không cần async(nghĩa là bạn có thể trả lại Tasktrực tiếp), sau đó không sử dụng async.

Có một số tình huống return awaithữu ích, như nếu bạn có hai thao tác không đồng bộ để thực hiện:

var intermediate = await FirstAsync();
return await SecondAwait(intermediate);

Để biết thêm về asynchiệu suất, xem bài viết và video MSDN của Stephen Toub về chủ đề này.

Cập nhật: Tôi đã viết một bài đăng trên blog chi tiết hơn nhiều.

Lý do duy nhất bạn muốn làm là nếu có một số mã khác awaittrong mã trước đó hoặc nếu bạn bằng cách nào đó thao túng kết quả trước khi trả lại. Một cách khác trong đó có thể xảy ra là thông qua try/catchthay đổi cách xử lý ngoại lệ. Nếu bạn không làm bất cứ điều gì thì bạn đúng, không có lý do gì để thêm chi phí cho việc thực hiện phương pháp async.

Một trường hợp khác bạn có thể cần chờ kết quả là trường hợp này:

async Task<IFoo> GetIFooAsync()
{
    return await GetFooAsync();
}

async Task<Foo> GetFooAsync()
{
    var foo = await CreateFooAsync();
    await foo.InitializeAsync();
    return foo;
}

Trong trường hợp này, GetIFooAsync()phải chờ kết quả GetFooAsyncvì loại Tkhác nhau giữa hai phương thức và Task<Foo>không được gán trực tiếp Task<IFoo>. Nhưng nếu bạn chờ đợi kết quả, nó sẽ trở thành Foothứ được gán trực tiếp IFoo. Sau đó, phương thức async chỉ đóng gói lại kết quả bên trong Task<IFoo>và bạn đi.

Làm cho phương thức "thunk" đơn giản khác không đồng bộ sẽ tạo ra một máy trạng thái không đồng bộ trong bộ nhớ trong khi phương thức không đồng bộ hóa thì không. Mặc dù điều đó thường có thể khiến mọi người sử dụng phiên bản không đồng bộ vì nó hiệu quả hơn (điều đó đúng) nhưng điều đó cũng có nghĩa là trong trường hợp bị treo, bạn không có bằng chứng nào cho thấy phương pháp đó có liên quan đến "ngăn xếp trả lại / tiếp tục" mà đôi khi làm cho nó khó khăn hơn để hiểu hang.

Vì vậy, vâng, khi perf không quan trọng (và thường là không) Tôi sẽ ném async vào tất cả các phương thức này để tôi có máy trạng thái async để giúp tôi chẩn đoán bị treo sau đó và cũng để đảm bảo rằng nếu chúng không phương pháp thunk từng phát triển theo thời gian, họ sẽ chắc chắn trả lại các nhiệm vụ bị lỗi thay vì ném.

Nếu bạn không sử dụng trả lại, chờ đợi, bạn có thể phá hỏng dấu vết ngăn xếp của mình trong khi gỡ lỗi hoặc khi nó được in trong nhật ký ngoại lệ.

Khi bạn trả lại tác vụ, phương thức đã hoàn thành mục đích của nó và nó nằm ngoài ngăn xếp cuộc gọi. Khi bạn sử dụng, return awaitbạn sẽ để nó trong ngăn xếp cuộc gọi.

Ví dụ:

Ngăn xếp cuộc gọi khi sử dụng await: A đang chờ tác vụ từ B => B đang chờ tác vụ từ C

Ngăn xếp cuộc gọi khi không sử dụng await: A đang chờ tác vụ từ C, mà B đã trả về.

Điều này cũng làm tôi bối rối và tôi cảm thấy rằng các câu trả lời trước đó đã bỏ qua câu hỏi thực tế của bạn:

Tại sao sử dụng cấu trúc trả về đang chờ khi bạn có thể trực tiếp trả về Tác vụ từ lệnh gọi DoAnotherT BreathAsync () bên trong?

Vâng đôi khi bạn thực sự muốn một Task<SomeType>, nhưng hầu hết thời gian bạn thực sự muốn một ví dụ SomeType, đó là, kết quả từ nhiệm vụ.

Từ mã của bạn:

async Task<SomeResult> DoSomethingAsync()
{
    using (var foo = new Foo())
    {
        return await foo.DoAnotherThingAsync();
    }
}

Một người không quen thuộc với cú pháp (ví dụ như tôi) có thể nghĩ rằng phương thức này sẽ trả về một Task<SomeResult>, nhưng vì nó được đánh dấu async, nên có nghĩa là kiểu trả về thực tế của nó là SomeResult. Nếu bạn chỉ sử dụng return foo.DoAnotherThingAsync(), bạn sẽ trả về một Tác vụ, sẽ không biên dịch. Cách chính xác là trả về kết quả của nhiệm vụ, vì vậy return await.