Tôi đã cố gắng học lập trình đa luồng trong C # và tôi bối rối về việc khi nào nên sử dụng một nhóm luồng so với việc tạo các luồng của riêng tôi. Một cuốn sách khuyên bạn nên sử dụng nhóm luồng cho các nhiệm vụ nhỏ (bất kể điều đó có nghĩa là gì), nhưng tôi dường như không thể tìm thấy bất kỳ hướng dẫn thực sự nào. Một số cân nhắc bạn sử dụng khi đưa ra quyết định lập trình này là gì?
Câu trả lời:
Nếu bạn có nhiều tác vụ logic yêu cầu xử lý liên tục và bạn muốn thực hiện song song, hãy sử dụng nhóm + bộ lập lịch.
Nếu bạn cần thực hiện đồng thời các tác vụ liên quan đến IO của mình như tải xuống nội dung từ máy chủ từ xa hoặc truy cập đĩa, nhưng cần thực hiện việc này một lần trong vài phút, sau đó tạo chủ đề của riêng bạn và tiêu diệt chúng sau khi bạn hoàn thành.
Chỉnh sửa: Về một số cân nhắc, tôi sử dụng nhóm luồng để truy cập cơ sở dữ liệu, vật lý / mô phỏng, AI (trò chơi) và cho các tác vụ theo kịch bản chạy trên các máy ảo xử lý nhiều tác vụ do người dùng xác định.
Thông thường một nhóm bao gồm 2 luồng trên mỗi bộ xử lý (rất có thể là 4 ngày nay), tuy nhiên bạn có thể thiết lập số lượng luồng bạn muốn, nếu bạn biết bạn cần bao nhiêu.
Chỉnh sửa: Lý do để tạo các chủ đề của riêng bạn là do thay đổi ngữ cảnh, (đó là khi các chủ đề cần trao đổi trong và ngoài quy trình, cùng với bộ nhớ của chúng). Có những thay đổi ngữ cảnh vô dụng, giả sử khi bạn không sử dụng các chủ đề của mình, chỉ cần để chúng ngồi xung quanh như người ta có thể nói, có thể dễ dàng giảm một nửa hiệu suất của chương trình của bạn (giả sử bạn có 3 luồng ngủ và 2 luồng hoạt động). Do đó, nếu các luồng tải xuống đó chỉ chờ chúng ăn hết hàng tấn CPU và làm mát bộ đệm cho ứng dụng thực của bạn
Tôi sẽ đề nghị bạn sử dụng nhóm luồng trong C # vì những lý do tương tự như bất kỳ ngôn ngữ nào khác.
Khi bạn muốn giới hạn số lượng luồng đang chạy hoặc không muốn chi phí tạo và hủy chúng, hãy sử dụng nhóm luồng.
Theo các nhiệm vụ nhỏ, cuốn sách bạn đọc có nghĩa là các nhiệm vụ có thời gian tồn tại ngắn. Nếu phải mất mười giây để tạo một luồng chỉ chạy trong một giây, thì đó là một nơi bạn nên sử dụng nhóm (bỏ qua số liệu thực tế của tôi, đó là tỷ lệ được tính).
Nếu không, bạn dành phần lớn thời gian của mình để tạo và hủy các luồng thay vì chỉ đơn giản là thực hiện công việc mà họ dự định sẽ làm.
Dưới đây là một bản tóm tắt hay về nhóm chủ đề trong .Net: http://bloss.msdn.com/pedram/archive/2007/08/05/docate-thread-or-a-threadpool-thread.aspx
Bài đăng cũng có một số điểm khi bạn không nên sử dụng nhóm chủ đề và thay vào đó bắt đầu chủ đề của riêng bạn.
Tôi đặc biệt khuyên bạn nên đọc cuốn sách điện tử miễn phí này: Threading in C # của Joseph Albahari
Ít nhất hãy đọc phần "Bắt đầu". Sách điện tử cung cấp một giới thiệu tuyệt vời và bao gồm rất nhiều thông tin luồng tiên tiến là tốt.
Biết có hay không sử dụng nhóm luồng chỉ là khởi đầu. Tiếp theo, bạn sẽ cần xác định phương pháp nào để nhập nhóm luồng phù hợp nhất với nhu cầu của bạn:
Cuốn sách điện tử này giải thích tất cả những điều này và khuyên khi nào nên sử dụng chúng so với tạo chủ đề của riêng bạn.
Nhóm luồng được thiết kế để giảm chuyển đổi ngữ cảnh giữa các luồng của bạn. Hãy xem xét một quá trình có một số thành phần đang chạy. Mỗi thành phần đó có thể tạo ra các luồng công nhân. Càng nhiều luồng trong quy trình của bạn, càng lãng phí thời gian vào việc chuyển ngữ cảnh.
Bây giờ, nếu mỗi thành phần đó đang xếp hàng các mục vào nhóm luồng, bạn sẽ có ít chi phí chuyển đổi ngữ cảnh hơn.
Nhóm luồng được thiết kế để tối đa hóa công việc đang được thực hiện trên các CPU của bạn (hoặc lõi CPU). Đó là lý do tại sao, theo mặc định, nhóm luồng sẽ tạo ra nhiều luồng trên mỗi bộ xử lý.
Có một số tình huống mà bạn không muốn sử dụng nhóm luồng. Nếu bạn đang chờ vào I / O, hoặc chờ đợi vào một sự kiện, v.v. thì bạn buộc lại chuỗi chủ đề nhóm đó và nó không thể được sử dụng bởi bất kỳ ai khác. Ý tưởng tương tự áp dụng cho các tác vụ chạy dài, mặc dù những gì tạo thành một tác vụ chạy dài là chủ quan.
Pax Diablo cũng làm cho một điểm tốt. Quay lên chủ đề không miễn phí. Phải mất thời gian và họ tiêu thụ thêm bộ nhớ cho không gian ngăn xếp của họ. Nhóm luồng sẽ sử dụng lại các luồng để khấu hao chi phí này.
Lưu ý: bạn đã hỏi về việc sử dụng luồng nhóm luồng để tải xuống dữ liệu hoặc thực hiện I / O đĩa. Bạn không nên sử dụng một chủ đề nhóm chủ đề cho việc này (vì những lý do tôi đã nêu ở trên). Thay vào đó sử dụng I / O không đồng bộ (còn gọi là phương thức BeginXX và EndXX). Đối với một FileStreamđó sẽ được BeginReadvà EndRead. Đối với một HttpWebRequestđó sẽ được BeginGetResponsevà EndGetResponse. Chúng phức tạp hơn để sử dụng, nhưng chúng là cách thích hợp để thực hiện I / O đa luồng.
Cảnh giác với nhóm luồng .NET cho các hoạt động có thể chặn bất kỳ phần quan trọng, biến hoặc không xác định nào trong quá trình xử lý của chúng, vì nó dễ bị bỏ đói luồng. Xem xét sử dụng các phần mở rộng song song .NET, cung cấp một số lượng trừu tượng logic tốt cho các hoạt động theo luồng. Chúng cũng bao gồm một trình lập lịch biểu mới, đây sẽ là một cải tiến trên ThreadPool. Xem tại đây
Một lý do để chỉ sử dụng nhóm luồng cho các tác vụ nhỏ là có một số lượng hạn chế của luồng nhóm luồng. Nếu một cái được sử dụng trong một thời gian dài thì nó sẽ ngăn luồng đó được sử dụng bởi mã khác. Nếu điều này xảy ra nhiều lần thì nhóm luồng có thể được sử dụng hết.
Sử dụng lên nhóm luồng có thể có các hiệu ứng tinh tế - một số bộ định thời .NET sử dụng các luồng của luồng luồng và sẽ không kích hoạt, chẳng hạn.
Nếu bạn có một tác vụ nền sẽ tồn tại trong một thời gian dài, như trong toàn bộ thời gian của ứng dụng của bạn, thì việc tạo chủ đề của riêng bạn là một điều hợp lý. Nếu bạn có các công việc ngắn cần được thực hiện trong một luồng, thì hãy sử dụng tổng hợp luồng.
Trong một ứng dụng mà bạn đang tạo nhiều luồng, chi phí tạo ra các luồng trở nên đáng kể. Sử dụng nhóm luồng tạo ra các luồng một lần và tái sử dụng chúng, do đó tránh được chi phí tạo luồng.
Trong một ứng dụng mà tôi đã làm việc, việc thay đổi từ việc tạo các luồng thành sử dụng nhóm luồng cho các luồng tồn tại ngắn thực sự đã hỗ trợ thông qua việc đặt ứng dụng.
Để có hiệu suất cao nhất với các đơn vị thực thi đồng thời, hãy viết nhóm luồng của riêng bạn, trong đó nhóm đối tượng Thread được tạo khi khởi động và chuyển sang chặn (trước đây bị treo), chờ trên ngữ cảnh để chạy (một đối tượng có giao diện chuẩn được triển khai bởi ma cua ban).
Vì vậy, nhiều bài viết về Nhiệm vụ so với Chủ đề so với .NET ThreadPool không thực sự cung cấp cho bạn những gì bạn cần để đưa ra quyết định về hiệu suất. Nhưng khi bạn so sánh chúng, Chủ đề thắng và đặc biệt là nhóm Chủ đề. Chúng được phân phối tốt nhất trên các CPU và chúng khởi động nhanh hơn.
Điều cần thảo luận là thực tế rằng đơn vị thực thi chính của Windows (bao gồm cả Windows 10) là một luồng và chi phí chuyển đổi bối cảnh của hệ điều hành thường không đáng kể. Nói một cách đơn giản, tôi không thể tìm thấy bằng chứng thuyết phục về nhiều bài viết này, cho dù bài viết có yêu cầu hiệu suất cao hơn bằng cách lưu chuyển đổi ngữ cảnh hoặc sử dụng CPU tốt hơn.
Bây giờ cho một chút hiện thực:
Hầu hết chúng ta sẽ không cần ứng dụng của mình mang tính quyết định và hầu hết chúng ta không có nền tảng khó khăn với các luồng, ví dụ, thường đi kèm với việc phát triển một hệ điều hành. Những gì tôi viết ở trên không dành cho người mới bắt đầu.
Vì vậy, những gì có thể quan trọng nhất là thảo luận là những gì dễ lập trình.
Nếu bạn tạo nhóm luồng của riêng mình, bạn sẽ có một chút văn bản để làm vì bạn cần quan tâm đến việc theo dõi trạng thái thực thi, cách mô phỏng tạm dừng và tiếp tục và cách hủy thực thi - bao gồm trong toàn ứng dụng tắt. Bạn cũng có thể phải quan tâm đến việc bạn có muốn tự động phát triển hồ bơi của mình hay không và giới hạn khả năng của hồ bơi của bạn là gì. Tôi có thể viết một khung như vậy trong một giờ nhưng đó là vì tôi đã thực hiện nó rất nhiều lần.
Có lẽ cách dễ nhất để viết một đơn vị thực thi là sử dụng Tác vụ. Vẻ đẹp của Nhiệm vụ là bạn có thể tạo một nhiệm vụ và khởi động nó trong dòng mã của mình (mặc dù có thể cần thận trọng). Bạn có thể chuyển mã thông báo hủy để xử lý khi bạn muốn hủy Tác vụ. Ngoài ra, nó sử dụng cách tiếp cận lời hứa để xâu chuỗi các sự kiện và bạn có thể yêu cầu nó trả về một loại giá trị cụ thể. Hơn nữa, với async và đang chờ, sẽ có nhiều tùy chọn hơn và mã của bạn sẽ dễ mang theo hơn.
Về bản chất, điều quan trọng là phải hiểu những ưu và nhược điểm với Nhiệm vụ so với Chủ đề so với .NET ThreadPool. Nếu tôi cần hiệu suất cao, tôi sẽ sử dụng các chủ đề, và tôi thích sử dụng nhóm của riêng tôi.
Một cách dễ dàng để so sánh là khởi động 512 Chủ đề, 512 Nhiệm vụ và 512 Chủ đề ThreadPool. Bạn sẽ thấy sự chậm trễ khi bắt đầu với Chủ đề (do đó, tại sao lại viết một nhóm chủ đề), nhưng tất cả 512 Chủ đề sẽ chạy trong vài giây trong khi các chủ đề Nhiệm vụ và .NET ThreadPool mất đến vài phút để bắt đầu.
Dưới đây là kết quả của một thử nghiệm như vậy (i5 lõi tứ với 16 GB RAM), cho mỗi 30 giây để chạy. Mã được thực thi thực hiện I / O tệp đơn giản trên ổ SSD.
Nhóm luồng là tuyệt vời khi bạn có nhiều tác vụ để xử lý hơn các luồng có sẵn.
Bạn có thể thêm tất cả các tác vụ vào nhóm luồng và chỉ định số lượng luồng tối đa có thể chạy tại một thời điểm nhất định.
Kiểm tra này trang trên MSDN: http://msdn.microsoft.com/en-us/library/3dasc8as(VS.80).aspx
Luôn luôn sử dụng một nhóm luồng nếu bạn có thể, làm việc ở mức độ trừu tượng cao nhất có thể. Nhóm luồng ẩn tạo và hủy chủ đề cho bạn, đây thường là một điều tốt!
Hầu hết thời gian bạn có thể sử dụng nhóm khi bạn tránh quá trình tạo chủ đề tốn kém.
Tuy nhiên trong một số tình huống bạn có thể muốn tạo một chủ đề. Ví dụ: nếu bạn không phải là người duy nhất sử dụng nhóm luồng và luồng bạn tạo sẽ tồn tại lâu dài (để tránh tiêu tốn tài nguyên được chia sẻ) hoặc ví dụ nếu bạn muốn kiểm soát ngăn xếp của luồng.
Đừng quên điều tra nhân viên nền.
Tôi tìm thấy rất nhiều tình huống, nó mang lại cho tôi những gì tôi muốn mà không cần phải nâng vật nặng.
Chúc mừng.
Tôi thường sử dụng Threadpool bất cứ khi nào tôi cần làm gì đó trên một chủ đề khác và không thực sự quan tâm khi nó chạy hoặc kết thúc. Một cái gì đó như đăng nhập hoặc thậm chí có thể tải xuống nền một tệp (mặc dù có nhiều cách tốt hơn để làm theo kiểu không đồng bộ đó). Tôi sử dụng chủ đề của riêng tôi khi tôi cần kiểm soát nhiều hơn. Ngoài ra, những gì tôi đã tìm thấy là sử dụng hàng đợi Themesafe (hack của riêng bạn) để lưu trữ "đối tượng lệnh" là tốt khi tôi có nhiều lệnh mà tôi cần để làm việc trong> 1 luồng. Vì vậy, bạn có thể tách một tệp Xml và đặt từng phần tử vào hàng đợi và sau đó có nhiều luồng xử lý khi thực hiện một số xử lý trên các phần tử này. Tôi đã viết một cách xếp hàng như vậy trong uni (VB.net!) Mà tôi đã chuyển đổi thành C #. Tôi đã bao gồm nó bên dưới không có lý do cụ thể (mã này có thể có một số lỗi).
using System.Collections.Generic;
using System.Threading;
namespace ThreadSafeQueue {
public class ThreadSafeQueue<T> {
private Queue<T> _queue;
public ThreadSafeQueue() {
_queue = new Queue<T>();
}
public void EnqueueSafe(T item) {
lock ( this ) {
_queue.Enqueue(item);
if ( _queue.Count >= 1 )
Monitor.Pulse(this);
}
}
public T DequeueSafe() {
lock ( this ) {
while ( _queue.Count <= 0 )
Monitor.Wait(this);
return this.DeEnqueueUnblock();
}
}
private T DeEnqueueUnblock() {
return _queue.Dequeue();
}
}
}Tôi muốn có một nhóm luồng để phân phối công việc trên các lõi với độ trễ càng ít càng tốt và điều đó không phải chơi tốt với các ứng dụng khác. Tôi thấy rằng hiệu năng nhóm luồng .NET không tốt như nó có thể. Tôi biết tôi muốn một luồng trên mỗi lõi, vì vậy tôi đã viết lớp thay thế nhóm luồng của riêng mình. Mã được cung cấp dưới dạng câu trả lời cho một câu hỏi StackOverflow khác tại đây .
Đối với câu hỏi ban đầu, nhóm luồng rất hữu ích để phá vỡ các tính toán lặp đi lặp lại thành các phần có thể được thực thi song song (giả sử chúng có thể được thực thi song song mà không thay đổi kết quả). Quản lý luồng thủ công rất hữu ích cho các tác vụ như UI và IO.