async & await - cuộc thăm dò cho các lựa chọn thay thế [đã đóng]

Bây giờ chúng tôi đã biết những gì đang có trong c # 5, rõ ràng vẫn còn một cơ hội cho chúng tôi ảnh hưởng đến việc lựa chọn hai từ khóa mới cho " Không đồng bộ " đã được công bố bởi Anders Heijsberg ngày hôm qua tại PDC10 .

async void ArchiveDocuments(List<Url> urls) {
    Task archive = null;
    for(int i = 0; i < urls.Count; ++i) {
        var document = await FetchAsync(urls[i]);
        if (archive != null)
            await archive;
        archive = ArchiveAsync(document);
    }
}

Eric Lippert có một lời giải thích về sự lựa chọn của hai từ khóa hiện tại và cách mà chúng đã bị hiểu sai trong các nghiên cứu về khả năng sử dụng. Các ý kiến ​​có một số đề xuất khác.

Xin vui lòng - một đề xuất cho mỗi câu trả lời, các bản sao sẽ bị thu hồi.

Cho rằng tôi không rõ về ý nghĩa / sự cần thiết của nó async, tôi thực sự không thể tranh luận với nó, nhưng gợi ý tốt nhất của tôi để thay thế awaitlà:

yield while (nhìn! không có từ khóa mới)

Lưu ý rằng đã suy nghĩ về điều này nhiều hơn một chút, tôi tự hỏi liệu sử dụng whilelại theo cách này có phải là một ý tưởng tốt hay không - xu hướng tự nhiên sẽ là mong đợi một boolean sau đó.

(Suy nghĩ: tìm từ khóa tốt cũng giống như tìm tên miền tốt :)

Làm thế nào về việc không có một từ khóa?

Tôi muốn trình biên dịch nhận ra rằng, hầu hết thời gian, khi tôi gọi một phương thức không đồng bộ, tôi muốn kết quả của nó.

Document doc = DownloadDocumentAsync();

Đó là nó. Lý do mọi người gặp khó khăn khi nghĩ ra một từ khóa cho việc này là vì nó giống như có một từ khóa để "làm điều bạn làm nếu mọi thứ hoàn toàn bình thường". Đó phải là mặc định, không yêu cầu một từ khóa.

Cập nhật

Ban đầu tôi đề nghị trình biên dịch nên thông minh với suy luận kiểu để tìm ra phải làm gì. Nghĩ thêm về điều này, tôi vẫn giữ cách triển khai hiện có trong CTP, nhưng hãy thực hiện một vài bổ sung nhỏ cho nó, để giảm bớt các trường hợp bạn cần sử dụng awaittừ khóa một cách rõ ràng.

Chúng tôi phát minh ra một thuộc tính : [AutoAwait]. Điều này chỉ có thể được áp dụng cho các phương pháp. Một cách để áp dụng điều này vào phương pháp của bạn là đánh dấu nó async. Nhưng bạn cũng có thể làm điều đó bằng tay, ví dụ:

[AutoAwait]
public Task<Document> DownloadDocumentAsync()

Sau đó, bên trong bất kỳ asyncphương thức nào , trình biên dịch sẽ cho rằng bạn muốn chờ cuộc gọi đến DownloadDocumentAsync, vì vậy bạn không cần chỉ định nó. Bất kỳ cuộc gọi đến phương thức đó sẽ tự động chờ đợi nó.

Document doc = DownloadDocumentAsync();

Bây giờ, nếu bạn muốn "thông minh" và có được Task<Document>, bạn sử dụng một toán tử start, chỉ có thể xuất hiện trước một cuộc gọi phương thức:

Task<Document> task = start DownloadDocumentAsync();

Tôi gọn gàng. Bây giờ một cuộc gọi phương thức đơn giản có nghĩa là những gì nó thường có nghĩa là: chờ cho phương thức hoàn thành. Và startchỉ ra điều gì đó khác biệt: đừng chờ đợi.

Đối với mã xuất hiện bên ngoài một asyncphương thức, cách duy nhất bạn được phép gọi một [AutoAwait]phương thức là bằng cách thêm tiền tố vào đó start. Điều này buộc bạn phải viết mã có cùng ý nghĩa bất kể nó có xuất hiện trong một asyncphương thức hay không.

Rồi tôi bắt đầu tham lam! :)

Đầu tiên, tôi muốn asyncáp dụng các phương thức giao diện:

interface IThing
{
    async int GetCount();
} 

Về cơ bản, điều đó có nghĩa là phương thức thực hiện phải trả về Task<int>hoặc một cái gì đó tương thích awaitvà người gọi phương thức sẽ có [AutoAwait]hành vi.

Ngoài ra khi tôi thực hiện phương pháp trên, tôi muốn có thể viết:

async int GetCount()

Vì vậy, tôi không phải đề cập đến Task<int>như là loại trả lại.

Ngoài ra, tôi muốn asyncáp dụng cho các loại đại biểu (mà suy cho cùng, giống như các giao diện với một phương thức). Vì thế:

public async delegate TResult AsyncFunc<TResult>();

Một asyncđại biểu đã - bạn đoán nó - [AutoAwait]hành vi. Từ một asyncphương thức bạn có thể gọi nó và nó sẽ tự động được chỉnh sửa await(trừ khi bạn chọn chỉ startnó). Và nếu bạn nói:

AsyncFunc<Document> getDoc = DownloadDocumentAsync;

Điều đó chỉ hoạt động. Đây không phải là một cuộc gọi phương thức. Chưa có nhiệm vụ nào được bắt đầu - async delegateđây không phải là một nhiệm vụ. Đó là một nhà máy để thực hiện các nhiệm vụ. Bạn có thể nói:

Document doc = getDoc();

Và điều đó sẽ bắt đầu một nhiệm vụ và chờ đợi nó kết thúc và cung cấp cho bạn kết quả. Hoặc bạn có thể nói:

Task<Document> t = start getDoc();

Vì vậy, một nơi trong đó "đường ống dẫn nước" bị rò rỉ là nếu bạn muốn tạo một đại biểu cho một asyncphương thức, bạn phải biết sử dụng một async delegateloại. Vì vậy, thay vì Funcbạn phải nói AsyncFunc, và như vậy. Mặc dù một ngày nào đó loại điều đó có thể được sửa chữa bằng suy luận loại được cải thiện.

Một câu hỏi khác là điều gì sẽ xảy ra nếu bạn nói bắt đầu với một phương thức thông thường (không đồng bộ). Rõ ràng một lỗi biên dịch sẽ là lựa chọn an toàn. Nhưng có những khả năng khác.

hearken unto AsyncFetch(…)

(nếu bạn không hiểu, hãy đọc bài viết trên blog của Eric . Ít nhất thì nó tốt hơn for sooth Romeo wherefore art thou AsyncFetch(…))

Tôi nghĩ asynclà tốt, nhưng có lẽ đó là vì tôi liên kết nó với các trang ASP.NET async - cùng một ý tưởng.

Đối với awaittừ khóa tôi thích continue afterhoặc resume after.

Tôi không thích yieldhoặc bất kỳ biến thể nào của nó, bởi vì ngữ nghĩa là phương pháp có thể không bao giờ thực sự mang lại sự thực thi; nó phụ thuộc vào trạng thái của nhiệm vụ.

Tôi cũng đã thêm vào nhận xét trên blog của Eric, tôi không thấy bất kỳ vấn đề nào khi sử dụng cùng một từ khóa async

var data = async DownloadFileAsync(url);

Tôi chỉ bày tỏ rằng tôi muốn tải xuống tệp không đồng bộ. Có một chút dư thừa ở đây, "async" xuất hiện hai lần, vì nó cũng có trong tên phương thức. Trình biên dịch có thể cực kỳ thông minh và phát hiện quy ước rằng các phương thức kết thúc bằng "Async" là các phương thức async nguyên vẹn và thêm nó cho chúng tôi trong mã được biên dịch. Vì vậy, thay vào đó bạn chỉ muốn gọi

var data = async DownloadFile(url);

trái ngược với cách gọi đồng bộ

var data = DownloadFile(url);

Heck, chúng ta cũng có thể định nghĩa chúng theo cùng một cách, vì từ khóa async có trong khai báo của chúng ta, tại sao chúng ta phải thêm "Async" vào mỗi tên phương thức - trình biên dịch có thể làm điều đó cho chúng ta.

async = task - Đó là sửa đổi một hàm để trả về một tác vụ, vậy tại sao không sử dụng từ khóa "task"?

await = finish - Chúng ta không nhất thiết phải chờ, nhưng nhiệm vụ phải "kết thúc" trước khi sử dụng kết quả.

Tôi thích yield until. yield while, đã được đề xuất, là tuyệt vời và không giới thiệu bất kỳ từ khóa mới nào, nhưng tôi nghĩ "cho đến khi" nắm bắt hành vi tốt hơn một chút.

Tôi nghĩ yield <something>là một ý tưởng tuyệt vời, bởi vì năng suất đã nắm bắt được ý tưởng làm cho phần còn lại của phương pháp tiếp tục rất tốt. Có lẽ ai đó có thể nghĩ về một từ tốt hơn "cho đến khi."

Tôi chỉ muốn đăng ký phiếu bầu của mình cho đề xuất của Aaron G comefrom- cách sử dụng phù hợp đầu tiên tôi từng thấy trong tuyên bố COMEFROM của INTERCAL . Ý tưởng là nó trái ngược với GOTO (nhảy ra khỏi câu lệnh GOTO) ở chỗ nó làm cho một số vị trí trong mã của bạn chuyển sang câu lệnh COMEFROM.

Vì chúng ta đang làm việc với Task<T>s, nên sử dụng startnhư một từ khóa trước câu lệnh, như trong:

start var document = FetchAsync(urls[i]);

Điều đáng chú ý là F # cũng sử dụng asynctừ khóa trong quy trình làm việc không đồng bộ của nó, điều này khá giống với chức năng async mới trong C # 5. Vì vậy, tôi sẽ giữ một cái giống nhau

Đối với awaittừ khóa trong F #, họ chỉ sử dụng let!thay vì let. C # không có cú pháp gán giống nhau, vì vậy họ cần một cái gì đó ở phía bên phải của =dấu hiệu. Như Stewol đã nói, nó hoạt động giống như yieldvậy nên nó gần như là một biến thể của điều đó.

yield async FetchAsync(..)

Điều này hoàn toàn phù hợp với công cụ asyncsửa đổi mà bạn cần đưa vào phương thức bạn đang gọi. Và cũng là ngữ nghĩa của hiện tại yield return, bạn trả về và mang lại sự thực thi cho mã liệt kê trong khi trong trường hợp này bạn đang mang lại sự thực thi của mình cho phương thức không đồng bộ.

Hãy tưởng tượng nếu trong tương lai sẽ có những cách sử dụng khác yield, chúng ta có thể thêm một yield xtrong đó x là tính năng mới sáng bóng thay vì có tất cả các từ khóa khác nhau này để thực hiện hầu hết cùng một việc, mang lại hiệu quả thực thi.

Thành thật mà nói, tôi hoàn toàn không hiểu lập luận 'không mang lại kết quả thực thi'. Rốt cuộc, không phải điểm gọi phương thức khác đã là 'thực hiện năng suất' cho phương thức đó sao? Bất kể nó không đồng bộ hay không? Tôi đang thiếu một cái gì đó ở đây?

Và tốt cho bạn nếu asynctrả về đồng bộ nhưng có từ khóa ở đó sẽ biểu thị rằng có khả năng phương thức sẽ chạy không đồng bộ và bạn sẽ mang lại sự thực thi cho phương thức khác. Phương thức của bạn nên tính đến điều đó bất kể phương thức đó có thực sự thực hiện các cuộc gọi không đồng bộ hay không.

IMO Tôi nghĩ rằng các trường hợp 'không mang lại lợi nhuận' khác nhau là một chi tiết thực hiện. Tôi muốn bảo đảm tính nhất quán trong ngôn ngữ (nghĩa là sử dụng lại yield).

Còn về complete"Tôi muốn nhiệm vụ hoàn thành" thì sao?

Task<byte[]> downloadTask = DownloadFileAsync(url);
byte[] data = complete downloadTask;

task(để khai báo phương thức) và async(trong thân phương thức)