Chờ đợi vs Nhiệm vụ.Wait - Bế tắc?

Tôi không hiểu sự khác biệt giữa Task.Waitvà await.

Tôi có một cái gì đó tương tự như các chức năng sau trong dịch vụ ASP.NET WebAPI:

public class TestController : ApiController
{
    public static async Task<string> Foo()
    {
        await Task.Delay(1).ConfigureAwait(false);
        return "";
    }

    public async static Task<string> Bar()
    {
        return await Foo();
    }

    public async static Task<string> Ros()
    {
        return await Bar();
    }

    // GET api/test
    public IEnumerable<string> Get()
    {
        Task.WaitAll(Enumerable.Range(0, 10).Select(x => Ros()).ToArray());

        return new string[] { "value1", "value2" }; // This will never execute
    }
}

Nơi nào Getsẽ bế tắc.

Điều gì có thể gây ra điều này? Tại sao điều này không gây ra vấn đề khi tôi sử dụng chờ đợi chứ không phải là await Task.Delay?

Waitvà await- trong khi về mặt khái niệm tương tự - thực sự hoàn toàn khác nhau.

Waitsẽ đồng bộ chặn cho đến khi nhiệm vụ hoàn thành. Vì vậy, chủ đề hiện tại bị chặn theo nghĩa đen đang chờ nhiệm vụ hoàn thành. Theo nguyên tắc chung, bạn nên sử dụng " asynctất cả đường xuống"; đó là, đừng chặn asyncmã. Trên blog của mình, tôi đi vào chi tiết về cách chặn trong mã không đồng bộ gây ra bế tắc .

awaitsẽ chờ đợi không đồng bộ cho đến khi nhiệm vụ hoàn thành. Điều này có nghĩa là phương thức hiện tại bị "tạm dừng" (trạng thái của nó bị bắt) và phương thức trả về một tác vụ không hoàn chỉnh cho người gọi của nó. Sau đó, khi awaitbiểu thức hoàn thành, phần còn lại của phương thức được lên lịch như một phần tiếp theo.

Bạn cũng đã đề cập đến một "khối hợp tác", theo đó tôi giả sử bạn có nghĩa là một nhiệm vụ mà bạn đang Waitthực hiện có thể thực hiện trên chuỗi chờ. Có những tình huống điều này có thể xảy ra, nhưng đó là một sự tối ưu hóa. Có nhiều tình huống không thể xảy ra, như nếu tác vụ dành cho người lập lịch khác hoặc nếu nó đã bắt đầu hoặc nếu đó là tác vụ không phải mã (ví dụ như trong ví dụ mã của bạn: Waitkhông thể thực thi Delaytác vụ nội tuyến vì không có mã cho nó).

Bạn có thể tìm thấy async/ awaitgiới thiệu của tôi hữu ích.

Dựa trên những gì tôi đọc được từ các nguồn khác nhau:

An await biểu thức không chặn luồng mà nó đang thực thi. Thay vào đó, nó làm cho trình biên dịch đăng ký phần còn lại của asyncphương thức dưới dạng tiếp tục trên tác vụ được chờ đợi. Kiểm soát sau đó trả về cho người gọi asyncphương thức. Khi tác vụ hoàn thành, nó gọi tiếp tục và thực thi asyncphương thức tiếp tục ở nơi nó dừng lại.

Để đợi một đơn taskhoàn thành, bạn có thể gọi Task.Waitphương thức của nó . Một cuộc gọi đến Waitphương thức chặn luồng cuộc gọi cho đến khi cá thể lớp duy nhất đã hoàn thành thực thi. Wait()Phương thức không tham số được sử dụng để chờ vô điều kiện cho đến khi một tác vụ hoàn thành. Tác vụ mô phỏng công việc bằng cách gọiThread.Sleep phương thức để ngủ trong hai giây.

Bài viết này cũng là một đọc tốt.

Một số sự kiện quan trọng đã không được đưa ra trong các câu trả lời khác:

"Async await" phức tạp hơn ở cấp độ CIL và do đó tốn thời gian bộ nhớ và CPU.

Bất kỳ nhiệm vụ có thể bị hủy nếu thời gian chờ đợi là không thể chấp nhận.

Trong trường hợp "async await", chúng tôi không có xử lý cho một nhiệm vụ như vậy để hủy bỏ nó hoặc giám sát nó.

Sử dụng Nhiệm vụ linh hoạt hơn thì "async await".

Bất kỳ chức năng đồng bộ hóa có thể được bao bọc bởi async.

public async Task<ActionResult> DoAsync(long id) 
{ 
    return await Task.Run(() => { return DoSync(id); } ); 
} 

Tôi không hiểu lý do tại sao tôi phải sống với phương thức đồng bộ hóa và không đồng bộ mã hoặc sử dụng hack.