Я намагався вивчити багатопотокове програмування в C #, і я збентежений, коли найкраще використовувати пул потоків порівняно зі створенням власних потоків. Одна книга рекомендує використовувати пул потоків лише для невеликих завдань (що б це не означало), але я не можу знайти реальних вказівок. Які міркування ви використовуєте при прийнятті цього програмного рішення?
Відповіді:
Якщо у вас є багато логічних завдань, які потребують постійної обробки, і ви хочете, щоб це було зроблено паралельно, використовуйте пул + планувальник.
Якщо вам потрібно одночасно виконувати завдання, пов’язані з IO, такі як завантаження матеріалів з віддалених серверів або доступ до диска, але це потрібно робити раз на кілька хвилин, а потім створюйте власні теми та вбивайте їх, коли закінчите.
Редагувати: З деяких міркувань я використовую пули потоків для доступу до бази даних, фізики / моделювання, AI (ігри) та для сценаріїв, що виконуються на віртуальних машинах, які обробляють безліч заданих користувачем завдань.
Зазвичай пул складається з 2-х потоків на один процесор (напевно, це сьогодні 4), проте ви можете встановити потрібну кількість потоків, якщо ви знаєте, скільки вам потрібно.
Редагувати. Причина створювати власні потоки - це через зміну контексту (саме тоді, коли потокам потрібно підмінятись і виходити з процесу разом із їх пам'яттю). Скажімо, не змінюючи контекст, скажіть, коли ви не використовуєте свої теми, просто залишаючи їх сидіти, як можна сказати, може легко знизити продуктивність вашої програми (скажімо, у вас є 3 сплячих нитки та 2 активних нитки). Таким чином, якщо ті завантажуючі нитки просто чекають, вони з'їдають тонни процесора і охолоджують кеш для вашого реального застосування
Я б запропонував вам використовувати пул потоків у C # з тих же причин, що і будь-яка інша мова.
Якщо ви хочете обмежити кількість запущених потоків або не хочете накладних витрат на їх створення та знищення, використовуйте пул потоків.
Невеликими завданнями книга, яку ви читаєте, означає завдання з коротким терміном експлуатації. Якщо для створення потоку, який працює лише одну секунду, потрібно десять секунд, це одне місце, де ви повинні використовувати пули (ігноруйте мої фактичні цифри, це значення враховується).
Інакше ви витрачаєте основну частину свого часу на створення та руйнування ниток, а не просто виконуючи ту роботу, яку вони мають намір робити.
Ось приємний підсумок пулу потоків у .Net: http://blogs.msdn.com/pedram/archive/2007/08/05/dedicated-thread-or-a-threadpool-thread.aspx
У публікації також є деякі моменти, коли ви не повинні використовувати пул потоків і замість цього починати власну нитку.
Я настійно рекомендую прочитати цю безкоштовну електронну книгу: Threading in C # by Joseph Albahari
Принаймні прочитайте розділ "Початок роботи". Електронна книга надає чудовий вступ та включає також безліч передової інформації про нарізку.
Знання того, використовувати чи ні використовувати пул ниток - це лише початок. Далі вам потрібно буде визначити, який спосіб введення пулу потоків найбільше відповідає вашим потребам:
Ця електронна книга пояснює все це та радить коли їх використовувати порівняно зі створенням власної нитки.
Пул потоків призначений для зменшення переключення контексту між вашими потоками. Розглянемо процес, в якому працює кілька компонентів. Кожен з цих компонентів міг створювати робочі потоки. Чим більше тем у вашому процесі, тим більше часу витрачається на зміну контексту.
Тепер, якби кожен з цих компонентів мав чергування елементів до пулу потоків, у вас буде набагато менше контекстних комутацій накладних.
Пул потоків призначений для максимізації роботи, яка виконується у ваших процесорах (або ядрах процесора). Ось чому за замовчуванням пул потоків закручує кілька потоків на один процесор.
Є деякі ситуації, коли ви не хочете використовувати пул потоків. Якщо ви чекаєте вводу-виводу або очікуєте події тощо, тоді ви зв’яжете цю нитку пулу ниток, і її ніхто не може використовувати. Ця ж ідея стосується і довгих завдань, що виконуються, хоча те, що становить тривале завдання, є суб'єктивним.
Pax Diablo також добре підходить. Скручування ниток не є безкоштовним. Це потребує часу, і вони споживають додаткову пам’ять для свого простору. Пул потоків повторно використовуватиме потоки для амортизації цієї вартості.
Примітка. Ви запитували про використання потоку пулу потоків для завантаження даних або виконання вводу-виводу диска. Не слід використовувати для цього нитку пулу ниток (з причин, які я описав вище). Замість цього використовуйте асинхронний введення-вивід (він же методи BeginXX і EndXX). Бо таке, FileStreamщо було б BeginReadі EndRead. Бо це HttpWebRequestбуло б BeginGetResponseі EndGetResponse. Вони складніші у використанні, але вони є правильним способом виконання багатопотокового вводу / виводу.
Остерігайтеся пулу потоків .NET для операцій, які можуть блокувати будь-яку значну, змінну або невідому частину їх обробки, оскільки це схильне голодування ниток. Подумайте про використання паралельних розширень .NET, які забезпечують велику кількість логічних абстракцій над потоковими операціями. Вони також включають новий планувальник, який повинен бути вдосконаленням у ThreadPool. Дивіться тут
Однією з причин використовувати пул потоків лише для невеликих завдань є те, що існує обмежена кількість потоків пулу потоків. Якщо він використовується тривалий час, він зупиняє використання цієї нитки іншим кодом. Якщо це трапляється багато разів, тоді пул потоків може бути використаний.
Використання пулу потоків може мати тонкі ефекти - деякі .NET-таймери використовують нитки пулу потоків і, наприклад, не спрацьовують.
Якщо у вас є фонове завдання, яке триватиме довгий час, як і впродовж усього терміну служби вашої програми, то створити власну нитку - справа розумна. Якщо у вас є короткі завдання, які потрібно виконати в потоці, то використовуйте об'єднання ниток.
У програмі, де ви створюєте багато ниток, накладні витрати на створення ниток стають істотними. Використання пулу ниток створює нитки один раз і повторно використовує їх, таким чином уникаючи створення потоку над головою.
У програмі, над якою я працював, перехід від створення ниток до використання пулу ниток для короткотривалих потоків справді допоміг пройти через додаток.
Для отримання максимальної продуктивності з одночасно виконаними одиницями, напишіть власний пул потоків, де пул об’єктів нитки створюється при запуску і переходить до блокування (раніше призупинено), очікуючи запуску контексту (об'єкт зі стандартним інтерфейсом, реалізований ваш код).
Так багато статей про Tasks vs. Threads vs. .NET ThreadPool насправді не дають тобі, що потрібно для прийняття рішення про ефективність. Але коли їх порівнювати, нитки виграють і особливо пул ниток. Вони розподіляються найкраще по процесорам, і вони запускаються швидше.
Що слід обговорити, це той факт, що головним блоком виконання Windows (включаючи Windows 10) є потік, а контекстна комутація накладних режимів ОС зазвичай незначна. Простіше кажучи, я не зміг знайти переконливі докази багатьох цих статей, чи вимагає ця стаття більш високу ефективність завдяки збереженню переключення контексту або кращому використанню процесора.
Тепер трохи реалізму:
Більшості з нас не потрібно, щоб наш додаток був детермінованим, і більшість з нас не має жорсткого тла з нитками, що, наприклад, часто відбувається при розробці операційної системи. Те, що я писав вище, не для початківців.
Тож, що може бути найважливішим, - це обговорити, що легко запрограмувати.
Якщо ви створюєте власний пул потоків, вам доведеться трохи написати, оскільки вам потрібно буде займатися відстеженням стану виконання, як імітувати призупинення та відновлення та скасування виконання - в тому числі в додатку закрити. Можливо, вам також доведеться перейматися тим, чи хочете ви динамічно розростати свій пул, а також обмеженням потужності вашого пулу. Я можу написати таку рамку за годину, але це тому, що я робив це стільки разів.
Мабуть, найпростіший спосіб написання одиниці виконання - це використання Завдання. Краса Завдання полягає в тому, що ви можете створити її і відкинути її в рядку у своєму коді (хоча може бути обережним). Ви можете передати маркер скасування для обробки, коли ви хочете скасувати завдання. Крім того, він використовує підхід, який обіцяє прив'язувати події, і ви можете мати можливість повернути йому певний тип значення. Більше того, з асинхронізацією та очікуванням існує більше варіантів, і ваш код стане більш портативним.
По суті, важливо зрозуміти плюси і мінуси Завдання проти ниток проти .NET ThreadPool. Якщо мені потрібна висока продуктивність, я збираюся використовувати теми, і я вважаю за краще використовувати власний пул.
Простий спосіб порівняння - це запуск 512 ниток, 512 завдань та 512 ниток потоку пулу. Ви знайдете затримку на початку з Threads (отже, чому писати пул потоків), але всі 512 теми будуть запущені за кілька секунд, тоді як Tasks і .NET ThreadPool запускають до декількох хвилин, щоб усі почалися.
Нижче наводяться результати такого тесту (чотириядерний i5 з 16 ГБ оперативної пам’яті), що дає кожні 30 секунд для запуску. Виконаний код виконує прості введення / виведення файлів на SSD-накопичувачі.
Пули ниток чудові, коли у вас більше завдань для обробки, ніж доступні теми.
Ви можете додати всі завдання до пулу потоків і вказати максимальну кількість потоків, які можуть працювати в певний час.
Перевірте цю сторінку в MSDN: http://msdn.microsoft.com/en-us/library/3dasc8as(VS.80).aspx
Завжди використовуйте пул ниток, якщо можете, працюйте на максимально можливому рівні абстрагування. Басейни з нитками приховують створення та руйнування ниток, це, як правило, добре!
Більшу частину часу ви можете використовувати пул, оскільки уникнете дорогого процесу створення нитки.
Однак у деяких сценаріях ви можете створити потік. Наприклад, якщо ви не єдиний, хто використовує пул потоків, і створений вами потік є довговічним (щоб уникнути споживання спільних ресурсів) або, наприклад, якщо ви хочете контролювати розмір нитки потоку.
Не забудьте дослідити фонового працівника.
Я знаходжу для багатьох ситуацій, це дає мені просто те, що я хочу без важкого підйому.
Ура.
Зазвичай я використовую Threadpool, коли мені потрібно щось зробити на іншій нитці і мені зовсім не байдуже, коли він працює чи закінчується. Щось на кшталт реєстрації або, можливо, навіть фонового завантаження файлу (хоча є кращі способи зробити це в стилі асинхрон). Я використовую власну нитку, коли мені потрібно більше контролю. Також те, що я знайшов, - це використання черги Threadsafe (зламати свій власний) для зберігання "командних об'єктів", це добре, коли у мене є кілька команд, над якими мені потрібно працювати над> 1 потоком. Таким чином, ви можете розділити Xml-файл і поставити кожен елемент у чергу, а потім мати кілька потоків, які працюють над деякою обробкою цих елементів. Я написав таку чергу назад у uni (VB.net!), Що перетворився на C #. Я включив його нижче без особливих причин (цей код може містити деякі помилки).
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();
}
}
}Я хотів, щоб потоковий пул розподіляв роботу по ядрах з якомога меншою затримкою, і це не повинно було добре грати з іншими програмами. Я виявив, що продуктивність пулу потоків .NET не була такою хорошою, як могла бути. Я знав, що хочу один потік на ядро, тому написав власний клас замінника пулу потоків. Код надається як відповідь на інше питання StackOverflow тут .
Що стосується оригінального питання, пул потоків корисний для розбиття повторюваних обчислень на частини, які можна виконати паралельно (якщо припустити, що вони можуть виконуватися паралельно без зміни результату). Ручне управління нитками корисно для таких завдань, як UI та IO.