Асинхронні операції обчислення

Размещено на http://www.allbest.ru/

Асинхронні операції обчислення

Асинхронні операцій можна умовно розділити на дві категорії: операції обчислення та операції вводу-виводу. Основна різниця між цими категоріями в тому, що при асинхронних операцій вводу-виводу усю роботу виконує драйвер операційної системи, тому ця операція не потребує створення потоків.

До операцій обчислення, відносяться, наприклад, й такі операцій як: математичні обчислення, компіляція коду, перевірка тексту на помилки, пошук тощо.

Класс Thread

Найпростішим класом що реалізує концепцію багато потоковості є класс Thread.

Процес може створювати один або більше потоків для виконання частин програмного коду, пов'язаного з процесом. Слід використовувати делегат ThreadStart або ParameterizedThreadStart для завдання програмного коду, керованого потоком. За допомогою делегата ParameterizedThreadStart можна передавати дані в потокову процедуру.

Протягом свого існування потік завжди знаходиться в одному або більше станах, визначених в класі ThreadState. Для потоку можна запитувати планування рівня пріоритету, який визначається класом ThreadPriority, але не гарантується, що операційна система надасть його.

Метод GetHashCode надає ідентифікацію керованих потоків. Протягом життя потік не буде конфліктувати зі значеннями, отриманими від інших потоків, незалежно від домену програми, з якої виходить значення.

Ідентифікаційний номер потоку ThreadId операційної системи не має жорсткої взаємозв'язку з керованим потоком, так як некероване основне додаток може контролювати взаємозв'язок між керованими і некерованими потоками. Зокрема, складний хост може використовувати CLR Hosting API для планування декількох керованих потоків на один потік операційної системи або переміщення керованих потоків між різними потоками операційної системи.

Немає потреби в збереженні посилання на об'єкт Thread після запуску потоку. Потік продовжує виконуватися до завершення потокової процедури.

Починаючи с. NET Framework 4 змінюється поведінка деяких конструкторів потоку: тільки повністю довірений код може встановити максимальний розмір стека, значення якого більше, ніж розмір стека за замовчуванням (1 мегабайт). Якщо при виконанні коду з частковим довірою для параметра вказано більше значення, воно ігнорується і використовується розмір стека за замовчуванням. Виняток не виникає. Код на якому рівні довіри, може встановити значення максимального розміру стека, яке менше, ніж розмір стека за замовчуванням.

Пул потоків

Слід зазначити, що багато програм створюють потоки, які більшу частину часу знаходяться в сплячому стані, чекаючи, коли відбудеться подія. Інші потоки можуть входити в недіюче стан тільки для того, щоб періодично відновлювати активність для перевірки на наявність змін або оновлення відомостей про стан. Таким чином виникає потреба в частому створенні та знищенні потоків, що є не раціональним с точки зору використання. Для вирішенні цієї проблеми в. Net реалізовано ідею пулу потоків.

Концепція пулу потоків дозволяє використовувати потоки більш ефективно, надаючи додатком пул робочих потоків, керованих системою. Приклади операції, що використовують потоки пулу потоків:

· При створенні об'єкта Task або Task (Of TResult) для асинхронного виконання будь-якої задачі за замовчуванням планується виконувати це завдання в потоці з пулу потоків.

· Асинхронні таймери використовують пул потоків. Потоки з пулу потоків виконують зворотні виклики з класу System. Threading. Timer і ініціюють події з класу System. Timers. Timer.

· При використанні зареєстрованих дескрипторів очікування стан цих дескрипторів очікування відстежується системним потоком. Коли операція очікування завершується, робочий потік, що знаходиться в пулі, виконує відповідну функцію зворотного виклику.

Потоки в керованому пулі потоків є фоновими. Тобто їх властивості IsBackground мають значення true. Це означає, що потік з пулу потоків не підтримуватиме виконання програми після того, як всі потоки переднього плану завершили роботу.

Можна також помістити в чергу на обробку пулом потоків робочі елементи, не пов'язані з операцією очікування. Щоб запросити обробку робочого елементу потоком з пулу, слід викликати метод QueueUserWorkItem. Цей метод приймає як параметр посилання на метод або делегат, які будуть викликані потоком, обраним з пулу потоків. Після того, як робочий елемент поміщений в чергу, його обробка не може бути скасована.

Таймери з черги таймера і зареєстровані операції очікування також використовують пул потоків. Їх функції зворотного виклику поміщаються в чергу пулу потоків.

Для кожного процесу існує один пул потоків. Починаючи с. NET Framework 4, розмір за замовчуванням пулу потоків для процесу залежить від декількох факторів, таких як розмір віртуального адресного простору. Процес може викликати метод GetMaxThreads для визначення кількості потоків. Кількість потоків в пулі потоків може змінюватися за допомогою методу SetMaxThreads. Кожен потік використовує задані за замовчуванням розмір стека і пріоритет виконання.

Коли пул потоків повторно використовує потік, він не очищає дані в локальній пам'яті стека або в полях, помічених атрибутом ThreadStaticAttribute. Отже, дані, вміщені в локальне сховище стека одним методом, можуть бути доступні будь-якому іншому методу, виконується тим же потоком з пулу. Метод, який звертається до поля, позначеного атрибутом ThreadStaticAttribute, може виявити там різні дані, в залежності від того, яким саме потоком з пулу цей метод виконується.

PLINQ

Паралельний LINQ (PLINQ) є паралельною реалізацією шаблону LINQ. Запит PLINQ багато в чому нагадує непаралельних запит LINQ to Objects. Запити PLINQ, так само як послідовні запити LINQ, працюють в будь-якому джерелі даних IEnumerable або IEnumerable <T> в пам'яті і мають можливість відкладеного виконання, тобто вони не починають виконуватися, поки запит не перераховано. Основною відмінністю є те, що PLINQ намагається повністю використовувати можливості всіх процесорів в системі. Це досягається шляхом поділу джерела даних на сегменти і паралельного виконання запиту кожного сегмента в окремому робочому потоці на декількох процесорах. У багатьох випадках паралельне виконання означає, що запит виконується значно швидше.

Завдяки паралельного виконання PLINQ може значно збільшити продуктивність у порівнянні із застарілим кодом для певних типів запитів часто просто шляхом додавання операції запиту AsParallel до джерела даних. Однак паралелізм може привести до появи власних складнощів, і не всі операції запитів виконуються швидше в PLINQ. В дійсності, параллелизация фактично уповільнює виконання певних запитів. Таким чином, слід розуміти вплив різних проблем, наприклад упорядкування, на паралельні запити. Додаткові відомості див Загальне уявлення про прискорення виконання в PLINQ.

Режими виконання

За замовчуванням PLINQ є консервативним. Під час виконання інфраструктура PLINQ аналізує загальну структуру запиту. Якщо виконання запиту швидше за все прискориться за рахунок паралелізації, PLINQ розділяє вихідну послідовність на завдання, які можуть виконуватися одночасно. Якщо виконувати паралелізації запиту небезпечно, PLINQ просто виконує запит послідовно. Якщо PLINQ може вибирати між алгоритмом паралельної обробки, який потенційно вимагає великих витрат ресурсів, і алгоритмом послідовної обробки, що не вимагає великих витрат ресурсів, він вибирає алгоритм послідовної обробки за замовчуванням. Щоб вказати PLINQ вибрати алгоритм паралельної обробки, можна використовувати метод WithExecutionMode <TSource> та перерахування System. Linq. ParallelExecutionMode. Це корисно, якщо тестування та вимірювання показали, що певний запит буде виконувати швидше паралельно. Додаткові відомості див Практичне керівництво. Завдання режиму виконання в PLINQ.
Ступінь паралелізму

За замовчуванням PLINQ використовує всі процесори на головному комп'ютері до 64. Можна вказати PLINQ використовувати не більше вказаної кількості процесорів за допомогою методу WithDegreeOfParallelism <TSource>. Це корисно, коли потрібно переконатися, що інші процеси, що виконуються на комп'ютері, отримують певну кількість часу ЦП. У наступному фрагменті запит обмежується використанням не більше двох процесорів.

У випадках, коли запит виконує значний обсяг роботи, не обмеженої по швидкості обчислень, наприклад файловий ввід-висновок, може бути корисно вказати ступінь паралелізму більше, ніж кількість ядер в комп'ютері.

Впорядковані та невпорядковані паралельні запити

В деяких запитах оператор запиту повинен виробляти результати із збереженням порядку вихідної послідовності. Для цієї мети PLINQ надає оператор AsOrdered. AsOrdered відрізняється від AsSequential <TSource>. Послідовність AsOrdered як і раніше обробляється паралельно, але її результати буферизуются і сортуються. Оскільки збереження порядку зазвичай включає додаткову роботу, послідовність AsOrdered може оброблятися повільніше, ніж послідовність AsUnordered <TSource> за замовчуванням. Чи є певна впорядкована паралельна операція швидше, ніж послідовна, залежить від багатьох факторів.

Паралельні і послідовні запити

Деякі операції вимагають доставки вихідних даних послідовним чином. Оператори запиту ParallelEnumerable здійснюють повернення до послідовного режиму автоматично при необхідності. Для визначених користувачем операторів запиту і користувальницьких делегатів, що вимагають послідовного виконання, PLINQ надає метод AsSequential <TSource>. При використанні методу AsSequential <TSource> всі наступні оператори в запиті виконуються послідовно до повторного виклику методу AsParallel. Додаткові відомості див Практичне керівництво. Об'єднання паралельних і послідовних запитів LINQ.

Параметри для злиття результатів запиту

При паралельному виконанні запиту PLINQ його результати з кожного робочого потоку повинні бути об'єднані назад в основному потоці для використання циклом foreach (For Each в Visual Basic) або вставки в список або масив. В деяких випадках може бути корисно вказати певний вид операції злиття, наприклад для початку більш швидкого виробництва результатів. Для цього PLINQ підтримує метод WithMergeOptions <TSource> та перерахування ParallelMergeOptions.

Оператор ForAll

У послідовних запитах LINQ виконання відкладається, поки запит не буде перерахований або в циклі foreach (For Each в Visual Basic), або шляхом виклику методу, наприклад ToList <TSource>, ToArray <TSource> або ToDictionary. В PLINQ також можна використовувати foreach для виконання запиту і ітерації результатів. Однак сам оператор foreach не виконується паралельно, і тому потрібно об'єднати вихідні дані всіх паралельних завдань назад в потоці, в якому виконується цикл. В PLINQ оператор foreach можна використовувати, якщо необхідно зберегти остаточний порядок результатів запиту, а також при кожній обробці результатів послідовним чином, наприклад при виклику Console. WriteLine для кожного елемента. Для більш швидкого виконання запиту у випадках, коли збереження порядку не потрібно і безпосередньо обробка результатів може виконуватися паралельно, використовуйте метод ForAll <TSource> для виконання запиту PLINQ. ForAll <TSource> не виконує цей заключний крок злиття. У наступному прикладі коду показано, як використовувати метод ForAll <TSource>. Тут використовується об'єкт System. Collections. Concurrent. ConcurrentBag <T>, так як його оптимізація дозволяє додавати кілька потоків паралельно, не намагаючись при цьому видалити будь-які елементи.

На наступному малюнку показано відмінність між foreach і ForAll <TSource> з виконання запиту.

Відміна

PLINQ інтегрований з типами відміни в. NET Framework 4. Таким чином, на відміну від послідовних запитів LINQ to Objects, запити PLINQ можна відмінити. Щоб створити відміняються запит PLINQ, треба використати оператор WithCancellation <TSource> запиту і надайте примірник CancellationToken в якості аргументу. Якщо властивість IsCancellationRequested токена має значення true, PLINQ відзначить це, зупинить обробку всіх потоків і створить виняток OperationCanceledException.

Запит PLINQ може продовжити обробляти деякі елементи після завдання токена скасування.

Щоб збільшити швидкість відповіді, також можна відповідати на запити скасування в тривалих користувацьких делегатах. Додаткові відомості див Практичне керівництво. Скасування запиту PLINQ.

Примітиви синхронізації

При роботі з багатьма потоками виникає проблема синхронізації потоків. Для вирішення цієї проблеми в.NET було створенно систему примітивів синхронізації.

Існує два типи примітивів: примітиви рівня користувача і примітиви рівня ядра.

В свою чергу примітиви рівня користувача реалізується через дві конструкції: volatile та interlocked.

Ключове слово interlocked

Ключове слово volatile вказує, що поле може бути змінено декількома потоками, що виконуються одночасно. Поля, оголошені як volatile, не проходять оптимізацію компілятором, яка передбачає доступ за допомогою окремого потоку. Це гарантує наявність найбільш актуального значення в поле в будь-який час.

Як правило, модифікатор volatile використовується для поля, звернення до якого виконується через кілька потоків без використання оператора lock для доступу.

Ключове слово volatile можна застосовувати до полів наступних типів.

Типи вказівників. Зверніть увагу, що незважаючи на те, що сам вказівник може бути «volatile», об'єкт, на який він вказує, таким бути не може. Іншими словами, не можна оголосити покажчик «volatile».

Типи, такі як sbyte, byte, short, ushort, int, uint, char, float і bool.

Тип перерахування з одним з таких базових типів: byte, sbyte, short, ushort, int або uint.

Параметри універсальних типів, які є посилальними типами.

Ключове слово volatile можна застосувати тільки до полів класу або структури. Локальні змінні не можуть бути оголошені як volatile.

Ключове слово Interlocked

Interlocked - класс, що надає атомарні операції для змінних, загальнодоступних декільком потокам.

Методи цього класу захищені від помилок, які можуть виникнути при перемиканні контекстів планувальником в той час, коли потік оновлює змінну, а вона може бути доступна іншим потокам, або коли виконуються одночасно два потоки на різних процесорах. Члени цього класу не видають винятку.

Методи Increment і Decrement збільшують або зменшують значення змінної і зберігають результат в одній операції. На більшості комп'ютерів збільшення значення змінної не є атомарної операцією, а вимагає наступних кроків:

1. Завантажити значення з змінної екземпляру в регістр.

2. Збільшити або зменшити значення.

3. Зберегти значення в змінній екземпляру.

Якщо не використовувати методи Increment і Decrement, потік може бути перерваний після виконання перших двох кроків. Потім інший потік може виконати всі три кроки. Коли перший потік продовжить виконання, він переписує значення в змінну примірника, і ефект збільшення або зменшення значення, виконання другої потоком, втрачається.

Метод Exchange обмінює значення заданих змінних на рівні атомарних операцій. Метод CompareExchange поєднує в собі дві операції: порівнювання двох значень і збереження третього значення в одній із змінних, яке залежить від результату порівняння. Операції порівняння і обміну виконуються як атомарні.

Примітиви рівня ядра використовують для синхронізації механізми операційної системи, що з одного боку робить їх повільнішими, а з іншого боку дозволяє проводити синхронізацію між потоками.

AutoResetEvent

Повідомляє очікуючий потік про те, що сталося подія. Цей клас не успадковується.

AutoResetEvent дозволяє потокам взаємодіяти один з одним шляхом передачі сигналів. Як правило, цей клас використовується, коли потокам потрібно винятковий доступ до ресурсу потоками.

Потік чекає сигналу, викликаючи метод WaitOne при виникненні AutoResetEvent. Якщо AutoResetEvent знаходиться в несигнальному стані, потік буде заблокований, очікуючи сигналу потоку, зараз контролюючого ресурс, про те, що ресурс доступний (для цього викликається метод Set).

Виклик Set сигналізує події AutoResetEvent про необхідність звільнення очікує потоку. Подія AutoResetEvent залишається в сигнальному стані до звільнення одного очікує потоку, а потім повертається в несигнальному стан. Якщо немає очікують потоків, стан залишається сигнальним нескінченно.

Якщо потік викликає метод WaitOne, а AutoResetEvent знаходиться в сигнальному стані, потік не блокується. AutoResetEvent негайно звільняє потік і повертається в несигнальному стан.

Важливе зауваження Важливо

Немає ніякої гарантії, що кожен виклик методу Set звільнить потік. Якщо два виклики знаходяться настільки близько, що другий виклик відбувається до звільнення потоку, тоді звільняється тільки один потік. Це як, якщо б другий виклик не відбувся. Також, якщо Set викликається, коли немає очікують потоків і AutoResetEvent отримує сигнали, сигнал ніякого впливу ні на що не надає.

Можна контролювати початковий стан AutoResetEvent, передавши конструктору логічне значення; якщо початковий стан сигнальне, значення true, у противному випадку значення false.

Подія AutoResetEvent можна також використовувати з методами WaitAll і WaitAny, поміченими модифікатором static.

Додаткові відомості про механізми синхронізації потоків див AutoResetEvent основної документації.

Починаючи с. NET Framework версії 2.0 AutoResetEvent успадковується з нового класу EventWaitHandle. AutoResetEvent є функціонально еквівалентним EventWaitHandle, створеному за допомогою EventResetMode. AutoReset.

На відміну від класу AutoResetEvent, клас EventWaitHandle забезпечує доступ до іменованих системним синхронізованим подіям.

Застосований до даного типу або члену атрибут HostProtectionAttribute має таке значення властивості Resources: Synchronization | ExternalThreading. Атрибут HostProtectionAttribute не впливає на настільні додатки (зазвичай запускаються подвійним клацанням значка, введенням команди або URL-адреси в браузері). Додаткові відомості див в описі класу HostProtectionAttribute або в розділі програмування SQL Server і атрибути захисту основного додатка.

У наступному прикладі показано використання AutoResetEvent для послідовного випуску потоків (по одному за раз) за допомогою виклику методу Set (в базовому класі) при кожному натисканні користувачем клавіші Enter. У прикладі запускається три потоки, які очікують події AutoResetEvent, створеного в сигнальному стані. Перший потік негайно випускається, оскільки AutoResetEvent вже знаходиться в сигнальному стані. При цьому об'єкт AutoResetEvent скидається в несигнальному стан, щоб наступні потоки блокувалися. Блоковані потоки не звільняються до тих пір, поки користувач не випустить їх по одному натисканням клавіші Enter.

Після того, як потоки звільняються від першого AutoResetEvent, вони чекають іншого AutoResetEvent, створеного в стан несигнальному. Всі три потоки блокуються, щоб метод Set викликався три рази, щоб звільнити їх все.

Семафор

Обмежує кількість потоків, які можуть одночасно отримувати доступ до ресурсу або пулу ресурсів.

Потоки виконують вхід в семафор, викликаючи метод WaitOne, успадкований від класу WaitHandle, і звільняють семафор викликом методу Release.

Лічильник на семафорі зменшується на одиницю кожного разу, коли в семафор входить потік, і збільшується на одиницю, коли потік звільняє семафор. Коли лічильник дорівнює нулю, наступні запити блокуються, поки інші потоки не звільнять семафор. Коли семафор звільнений всіма потоками, лічильник має максимальне значення, задане при створенні семафора.

Гарантований порядок, в якому б блоковані потоки входили в семафор, наприклад FIFO або LIFO, відсутня.

Потік може виконувати вхід в семафор кілька разів, викликаючи багаторазово метод WaitOne. Щоб звільнити деякі з цих входів, потік може викликати перевантажений метод Release () без параметрів кілька разів, або викликати перевантажений метод Release (Int32), який вказує кількість звільняються входів.

Клас Semaphore не забезпечує потокової ідентифікації для викликів методів WaitOne або Release. Забезпечити, щоб потоки не звільняли семафор дуже багато раз - відповідальність програміста. Припустимо, наприклад, що у семафора максимальне значення лічильника дорівнює двом, і два потоки, A і B входять в семафор. Якщо помилка програмування в потоці B змушує його викликати метод Release двічі, обидва виклику закінчуються успішно. Лічильник на семафорі досяг максимального значення, і якщо потік A викличе метод Release, буде видано виняток SemaphoreFullException.

Семафори бувають двох типів: локальні семафори і іменовані системні семафори. При створенні об'єкта Semaphore за допомогою конструктора, що дозволяє передавати параметр з ім'ям семафора, об'єкт зв'язується з яких дане ім'я семафором операційної системи. Іменовані системні семафори доступні в межах всієї операційної системи і можуть бути використані для синхронізації дій процесів. Можна створити кілька об'єктів Semaphore, що представляють один і той же іменований системний семафор, і використовувати метод OpenExisting для відкриття існуючого іменованого системного семафора.

Локальний семафор існує тільки всередині одного процесу. Він може використовуватися будь-якою потоком в процесі, що має посилання на локальний об'єкт Semaphore. Кожен об'єкт Semaphore є окремим локальним семафором.

У наступному прикладі коду створюється семафор з максимальним значенням лічильника рівним 3 і вихідним значенням лічильника рівним 0. У прикладі запускаються п'ять потоків, які блокують очікування семафора. Головний потік використовує перевантажений метод Release (Int32) для збільшення лічильника семафора до максимального значення, дозволяючи трьом потокам увійти в семафор. У кожному потоці використовується метод Thread. Sleep для створення імітує роботу затримки, а потім викликається перевантажений метод Release () для звільнення семафора. Кожен раз при звільненні семафора відображається попереднє значення лічильника семафора. Виведені в консоль повідомлення дозволяють відстежувати використання семафора. Інтервал імітує роботу затримки трохи збільшений для кожного потоку, щоб вихідні дані було легше читати.

Мьютекс

Коли двом або більше потокам одночасно потрібен доступ до загального ресурсу, системі необхідний механізм синхронізації, щоб забезпечити використання ресурсу тільки одним потоком одночасно. Mutex - примітив, який надає ексклюзивний доступ до загального ресурсу тільки одному потік синхронізації. Якщо потік отримує семафор, другий потік, який бажає отримати цей семафор, призупиняється до тих пір, поки перший потік не звільнить семафор.

Можна використовувати метод WaitHandle. WaitOne для запиту на володіння семафором. Потік, який володіє семафором, може запитувати його в повторюваних виклики WaitOne без блокування виконання. Однак потік повинен викликати метод ReleaseMutex відповідну кількість разів для того, щоб припинити володіти семафором. Клас Mutex виконує ідентифікацію потоків, таким чином, мьютекс може звільнятися тільки потоком, який отримав його. Навпаки, клас Semaphore не забезпечує потокової ідентифікації.

Якщо потік завершується, володіючи мьютекс, то мьютекс називається кинутим. Стан мьютекса задається сигнальним, і мьютекс переходить у володіння наступного очікує потоку. Починаючи з версії 2.0 платформи. NET Framework, в наступному потоці, що отримав кинутий мьютекс, видається виняток AbandonedMutexException. У версіях платформи. NET Framework 2.0 і виняток не видавалася.

Покинутий мьютекс часто є ознакою серйозної помилки в коді. Коли потік завершує роботу без звільнення об'єкта мьютекса, захищені об'єктом мьютекса структури даних, можливо, не знаходяться в узгодженому стані. Наступний потік, який запитує володіння мьютекс, може обробити цей виняток і продовжити роботу, якщо зможе упевнитися в цілісності структури даних.

Кинутий системний мьютекс може свідчити про раптове припинення виконання програми (наприклад, за допомогою диспетчера завдань Windows).

Мьютекс бувають двох типів: локальні мьютекс (без імені), і іменовані системні мьютекс. Локальний мьютекс існує тільки всередині одного процесу. Він може використовуватися будь-якою потоком в процесі, який містить посилання на об'єкт Mutex, що представляє мьютекс. Кожен неіменовані об'єкт Mutex представляє окремий локальний мьютекс.

Іменовані системні мьютекс доступні в межах всієї операційної системи і можуть бути використані для синхронізації дій процесів. Можна створити об'єкт Mutex, що представляє іменований системний мьютекс, використовуючи конструктор з підтримкою імен. Об'єкт операційної системи може бути створений в той же час, або існувати до створення об'єкта Mutex. Можна створити кілька об'єктів Mutex, що представляють один і той же іменований системний мьютекс, і використовувати метод OpenExisting для відкриття існуючого іменованого системного мьютекса.

обчислення потік запит програмний

Размещено на Allbest.ru