Nên .Net 4.0 Nhiệm vụ luôn là phương pháp ưu tiên cho các ứng dụng đa luồng?

Question

Tôi đã đọc về các Task Parallel Library và bài viết nói:

Trong .NET Framework 4, nhiệm vụ là API ưa thích cho các văn bản đa luồng, không đồng bộ, và mã song song

Nhưng nó cũng nói rằng họ sử dụng ThreadPool đằng sau hậu trường. Những gì tôi gặp khó khăn trong việc tìm ra là nhiệm vụ chỉ nên được sử dụng khi bạn sử dụng ThreadPool (và vì vậy "Thread vs. Task" sẽ tương đương với "Thread so ThreadPool"), hoặc nếu Microsoft dự định sử dụng Tasks bất cứ nơi nào nhiều chủ đề được yêu cầu, mà không có những cân nhắc vốn có cho tình trạng tiến thoái lưỡng nan "Thread vs. ThreadPool".

Vì vậy, các Công việc có nên được sử dụng ở bất kỳ nơi nào có nhiều chủ đề được yêu cầu không?

Answer 1

Lợi thế thiết kế của việc sử dụng các tác vụ là bạn chuyển giao phần cứng của luồng cho thời gian chạy, có thể hoàn thành nhiệm vụ luồng bằng cách sử dụng một giải pháp ít lỗi hơn, tối ưu hơn. Tôi biết một số mô hình dựa trên nhiệm vụ, chẳng hạn như PLINQ, cho phép bạn gợi ý chiến lược mà thời gian chạy nên áp dụng, để câu hỏi "Threadpool hoặc không Threadpool" có thể được xử lý trực tiếp.

Việc chuyển sang mô hình này tương tự như chuyển sang ngôn ngữ được quản lý GC-ed so với ngôn ngữ yêu cầu bạn làm sạch bộ nhớ của riêng bạn. Sẽ luôn có những lập luận ủng hộ cho thứ hai, nhưng Garbage Collection giờ đây đã được tối ưu hóa đến mức thực tế nó không phải là vấn đề. Lý tưởng nhất, cơ chế chuyển đổi thời gian chạy cho các nhiệm vụ sẽ phát triển và trở nên tốt hơn. Vì vậy, về mặt lý thuyết, ứng dụng của bạn được viết và biên dịch cho .NET 4 có thể nhanh hơn với việc triển khai tốt hơn thời gian chạy mà không cần biên dịch lại. Ngoài ra, mã luồng là nổi tiếng khó có được quyền, vì vậy bất kỳ cơ chế nào ẩn các chi tiết đó đều tốt cho lập trình viên.

Liệu những lợi ích đó có lớn hơn các nguy cơ tiềm tàng, chẳng hạn như các trường hợp cạnh mà thời gian chạy không xử lý tốt, là điều cần được xem xét từng trường hợp. Tôi chắc chắn sẽ cố gắng không tối ưu hóa sớm ở đây, mặc dù.

Answer 2

Bạn có thể sử dụng TaskCreationOptions.LongRunning làm gợi ý cho TPL biết rằng nhiệm vụ của bạn có thể liên quan nhiều hơn những gì mà ThreadPool được điều chỉnh. Nhưng, vâng, TPL dường như là phương pháp ưa thích cho lập trình đa luồng nhìn về phía trước. Microsoft thậm chí còn xây dựng trên đầu trang của nó để hỗ trợ các từ khóa async và await mới được đề xuất trong Async CTP. Điều đó không có nghĩa là bạn phải từ bỏ các kiểu cũ Thread và ThreadPool APIs. Tuy nhiên, cá nhân tôi nhận thấy rằng TPL thực hiện hầu hết những gì tôi muốn trong một API thanh lịch hơn và tôi có xu hướng dựa vào nó hầu như bây giờ.

Answer 3

Nhiệm vụ là mức trừu tượng cao hơn so với luồng hoặc ThreadPool. Về cơ bản bạn đóng gói một chức năng trong một nhiệm vụ và yêu cầu thời gian chạy để thực hiện nó tốt nhất có thể. Bạn có thể có nhiều hàng chục nếu không phải là các nhiệm vụ sẽ được thực hiện bởi một số lượng hạn chế các chủ đề.

Sử dụng các tác vụ mà nhà phát triển tạo ra bao nhiêu tác vụ khi cần, nối chúng để tạo luồng (luồng công việc trong F #) và kiểm soát việc hủy của chúng mà không làm phiền đến cách phân bổ hoặc sử dụng luồng. Đó là vào thời gian chạy để chọn cách tốt nhất để thực hiện tất cả các nhiệm vụ bằng cách sử dụng số lượng hạn chế của chủ đề.

Công việc giúp việc triển khai các mẫu lập trình đồng thời dễ dàng hơn nhiều.Thư viện ParallelExtensionExtras cung cấp các phương thức để chuyển đổi cặp Begin/EndXXX thành các tác vụ có thể được ghép và một phiên bản sơ bộ của thành phần Lặp lại nhiệm vụ được sử dụng bởi Async CTP để cung cấp cú pháp async/await. Bạn có thể sử dụng ConcurrentCollection của các tác vụ để tạo hàng đợi công việc, tương tự như ví dụ AsyncCall trong ParallelExtensionExtras, hoặc đi xa hơn và tạo các tác nhân tương tự như Scala, Erlang hoặc F #. DataFlow trong CTP Async là một ví dụ khác về những gì bạn có thể tạo bằng các tác vụ.

Bạn phải ghi nhớ rằng trong khi một máy tính xách tay điển hình có 2 lõi và một máy tính để bàn điển hình có 4, máy chủ nhỏ đã có 8 lõi trở lên và chẳng bao lâu nữa chúng sẽ có nhiều hơn. Giữ tất cả những lõi bận rộn bằng cách lập lịch trình thủ công và tránh các khối có thể trở thành một nhức đầu lớn.