Научно-педагогическая практика

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

1. Тема, дата, время, характер учебного занятия

Занятие проводилось по курсу "Вычислительные системы и параллельная обработка данных".

Занятие было проведено __ мая 2016 года.

Начало занятия __ часов __ минут.

Тема занятия: специальная.

Характер занятия: лекция.

2. Количественный состав аудитории

Занятия проводилось со студентами четвертого курса специальности 221231 "Прикладная математика и информатика".

Количественный состав аудитории - __ человек.

Средний возраст студентов - 20 лет.

3. Предварительный хронометраж занятия и анализ его реализации

Предварительный хронометраж составил:

- знакомство с аудиторией - 1 минуты;

- опрос по прошедшим темам - 9 минут;

- объявление темы лекции и рассматриваемых на ней вопросов - 3 минута;

- чтение лекции, анализ графиков скорости выполнения, анализ представленной платформы программирования - 55 минут;

- выдано задание на лабораторную работу с подробным объяснением вариантов - 7 минуты;

- ответы на вопросы студентов - 15 минут.

На практике всё это было реализовано.

4. Выводы о достижении цели учебного занятия

В результате проведения занятия студенты должны были изучить новую тему. Их ответы на поставленные мной контрольные вопросы, а также высокий уровень вопросов, заданных самими студентами в конце занятия показывает, что цель учебного занятия достигнута. В ходе дискуссии, студентами был показан достаточно высокий уровень знания материала и по другим специальным дисциплинам и программированию в целом.

5. Предложения по осуществлению контроля прочитанной темы (примеры задач, практических заданий т.п.)

Для проверки внимания студентов в прочитанный материал были заданы контрольные вопросы и выдано задание на лабораторную работу по прочитанной лекции. Также материал прочитанной лекции войдёт в вопросы экзамене по этой дисциплине. обучение контроль педагогический

6. Текст лекции

Основы многопоточности в .NET Framework

Многопоточность -- одна из самых сложных тем в программировании, с ней постоянно возникает масса проблем. Без четкого понимания внутренних механизмов будет очень трудно предсказать результат работы приложения, использующего несколько потоков. Мы не будем здесь дублировать массу теоретической информации, которой очень много в сети и умных книгах. Вместо этого сконцентрируемся на конкретных и наиболее важных проблемах, на которые нужно обращать особое внимание и обязательно помнить о них в процессе разработки.

Потоки

Как все наверняка знают, поток в .NET Framework представлен в виде класса Thread. Разработчики могут создавать новые потоки, давать им осмысленные имена, изменять приоритет, запускать, ожидать завершения работы или останавливать.

Потоки делятся на background (фоновый) и foreground (основной, тот, что на переднем плане). Основное отличие между ними в том, что foreground-потоки препятствуют завершению программы. Как только все foreground-потоки остановлены, система автоматически остановит все background и завершит выполнение приложения. Чтобы определить, является поток фоновым или нет, необходимо вызвать следующее свойство текущего потока: Thread.CurrentThread.IsBackground

По умолчанию, при создании потока при помощи класса Thread мы получим foreground-поток. Для того, чтобы его поменять на фоновый, мы можем воспользоваться свойством thread.IsBackground.

В приложениях, которые имеют пользовательский интерфейс (UI), всегда есть как минимум один главный (GUI) поток, который отвечает за состояние компонентов интерфейса. Важно знать, что возможность изменять состояние представления есть только у этого, так называемого «UI-потока», который создается для приложения обычно в единственном экземпляре (хотя и не всегда).

Стоит также упомянуть про исключительные ситуации, которые могут возникать в дочерних потоках. В такой ситуации приложение будет экстренно завершено, и мы получим Unhandled Exception, даже если обернем код запуска потока в блок try/catch. В таком случае, обработку ошибок необходимо вынести в код дочернего потока, в котором уже можно будет отреагировать на конкретную исключительную ситуацию.

Применяя глобальную обработку исключений (Application_Error в ASP.NET, Application.DispatcherUnhandledException в WPF,Application.ThreadException в WinForms и т.д.) важно помнить, что при таком подходе мы сможем «ловить» исключительные ситуации, которые произошли ТОЛЬКО в UI потоке, то есть мы не «поймаем» исключения из дополнительных фоновых потоков. Также мы можем воспользоваться AppDomain.CurrentDomain.UnhandledException и вклиниться в процесс обработки всех необработанных исключительных ситуаций в рамках домена приложения, но мы никак не сможем воспрепятствовать процессу завершения приложения.

Потоки -- это дорогостоящие объекты, которые занимают память, могут использовать различные ресурсы системы и находиться в разных состояниях. Для их создания требуется время. В сравнении с процессами они менее ресурсоемки, но все же требуют довольно больших затрат на создание и уничтожение. Более того, за освобождение занимаемых конкретным потоком ресурсов отвечает разработчик. Например, для выполнения массы небольших задач неэффективно запускать множество потоков, так как издержки на их запуск могут превысить выгоду от использования. Для того, чтобы иметь возможность повторно использовать уже запущенные потоки и избавиться от издержек на создание, был введен так называемый пул-потоков (ThreadPool).

ThreadPool

В рамках каждого процесса CLR создает одну дополнительную абстракцию, которая называется пул потоков. Он представляет собой набор потоков, которые находятся в режиме ожидания и готовы выполнять любую полезную работу. При запуске приложения пул-потоков запускает минимальное количество потоков, которые находятся в состоянии ожидания новых задач. Если активных потоков недостаточно для эффективного выполнения задач в пуле, он запускает новые и использует их по тому же принципу повторного использования. Пул довольно умный и умеет определять необходимое эффективное количество потоков, а также останавливать лишние или запускать дополнительные. Можно задавать максимальное и минимальное количества потоков, но на практике это делают редко.

Потоки внутри пула разделяются на две группы: worker и I/O-потоки. Рабочие потоки фокусируются на работе, связанной с загрузкой CPU (CPU based), в то время как I/O-потоки -- на работе с устройствами ввода/вывода: файловая система, сетевая карта и другие. Если пытаться выполнять I/O-операцию на рабочем потоке (CPU based), то это будет напрасная трата ресурсов, так как поток будет находиться в состоянии ожидания завершения I/O-операции. Для подобных задач предназначены отдельные I/O-потоки. При использовании пула потоков это скрыто в явном виде от разработчиков. Получить количество разных потоков в пуле можно при помощи кода: ThreadPool.GetAvailableThreads(out workerThreads, out competitionPortThreads);

Для того, чтобы определить, является текущий поток взятым из пула или созданным вручную, необходимо воспользоваться конструкцией:

Thread.CurrentThread.IsThreadPoolThread

Запустить задачу на выполнение при помощи потока, взятого в пуле, можно с помощью:

· класса ThreadPool: ThreadPool.QueueUserWorkItem

· асинхронных делегатов (BeginInvoke() и EndInvoke())

· класса BackgroundWorker

· TPL (Task Parallel Library)

Следующие конструкции также используют пул потоков, но делают это неявно, о чем важно знать и помнить:

· WCF, Remoting, ASP.NET, ASMX Web Services

· System.Timers.Timer и System.Threading.Timer

· EAP (the event-based asynchronous pattern)

· PLINQ

Полезно держать в голове следующие моменты:

· Потокам из пула невозможно назначить имя

· Потоки из пула всегда фоновые (background)

· Блокировка потоков из пула может привести к запуску дополнительных потоков и падению производительности

· Вы можете поменять приоритет потоку из пула, но он вернется в дефолтное значение (normal) после возвращения в пул

Синхронизация

При построении многопоточного приложения необходимо гарантировать, что любая часть разделяемых данных защищена от возможности изменения их значений множеством потоков. Учитывая, что управляемая куча является одним из разделяемых потоками ресурсов, а все потоки в AppDomain имеют параллельный доступ к разделяемым данным приложения, очевидно, что доступ к таким общим данным необходимо синхронизировать. Это гарантирует, что в один момент времени доступ к определенному блоку кода получит лишь один поток (или указанное количество, в случае использования Семафора). Таким образом, мы можем гарантировать целостность данных, а также их актуальность в любой момент времени. Давайте рассмотрим возможные варианты синхронизации и частые проблемы. Говоря о синхронизации, обычно выделяют 4 вида:

· Блокировка вызывающего кода

· Конструкции, ограничивающие доступ к кускам кода

· Сигнализирующие конструкции

· Неблокирующая блокировка

Blocking

Под блокировкой понимается ожидание одним потоком завершения другого или нахождение в режиме ожидания в течение некоего времени. Обычно реализуется при помощи методов класса Thread: Sleep() и Join(), метода EndInvoke() асинхронных делегатов или при помощи тасков (Task) и их механизмов ожидания. Следующие конструкции являются примерами плохого подхода к реализации ожидания:

while (!proceed);

while (DateTime.Now < nextStartTime);

Подобные конструкции требуют много ресурсов процессора, хотя не выполняют никакой полезной работы. В то же время ОС и CLR думают, что наш поток занят выполнением важных расчетов и выделяют для него необходимые ресурсы. Данного подхода следует всегда избегать. Похожим примером может быть следующая конструкция:

while (!proceed) Thread.Sleep(10);

Здесь вызывающий поток периодически засыпает на короткое время, но его достаточно для того, чтобы система могла переключить контексты и выполнять параллельно другие задачи. Данный подход гораздо лучше предыдущего, но все же не идеален. Основная проблема возникает в тот момент, когда необходимо изменять флаг proceed из разных потоков. Подобная конструкция будет эффективным решением в том случае, когда мы ожидаем, что условие в цикле будет удовлетворено через очень короткое время и повлечет за собой небольшое количество итераций. Если итераций много, то системе потребуется постоянно переключать контекст данного потока и тратить на это дополнительные ресурсы.

Locking

Эксклюзивная блокировка применяется для того, чтобы удостовериться, что только один поток будет выполнять конкретный участок кода. Это необходимо для гарантирования актуальности данных в каждый момент времени. В .NET Framework существует довольно много механизмов, которые позволяют реализовать блокировку доступа к участкам кода, но мы рассмотрим только самые популярные. А заодно разберем наиболее частые ошибки, связанные с применением подобных конструкций.

Статические члены классов, которыми часто оперируют разработчики, всегда потоконебезопасны, и доступ к таким данным нужно обязательно синхронизировать. Отличием может быть только статический конструктор, так как CLR блокирует все обращения из сторонних потоков к статическим членам класса до тех пор, пока не завершит свою работу статический конструктор.

При использовании блокирования при помощи ключевого слова lock следует помнить о следующих правилах:

· необходимо избегать блокирования типов:

lock(typeof(object)) {…}

Дело в том, что каждый тип хранится в единственном экземпляре в рамках одного домена и подобный подход может привести к взаимоблокировкам. Поэтому стоит избегать подобных конструкций.

· необходимо избегать блокирования объекта this:

lock(this) {…}

Данный подход также может привести к взаимоблокировке.

· как объект синхронизации можно использовать дополнительное поле в конкретном классе:

lock(this.lockObject) {…}

· нужно применять конструкцию Monitor.TryEnter(this.lockObject, 3000) когда вы сомневаетесь, и поток может быть заблокирован. Подобная конструкция позволит выйти из блокировки по истечении указанного интервала времени.

необходимо использовать класс Interlocked для атомарных операций вместо подобных конструкций:

lock (this.lockObject) { this.counter++; }

Signaling

Данный механизм позволяет потоку остановиться и ожидать до тех пор, пока он не получит извещение из другого потока о возможности продолжить работу.

.NET Framework предоставляет конструкции, которые могут выполнять простые операции без блокировки, остановки или ожидания других потоков. За счет отсутствия блокировок и переключения контекстов код будет работать быстрее, но при этом очень легко допустить ошибку, которая чревата труднонаходимыми проблемами. В конечном счете ваш код может стать даже медленнее, чем если бы вы применили распространенный подход с использованием lock. Одним из вариантов подобной синхронизации является применение так называемых барьеров памяти (Thread.MemoryBarrier()), которые препятствуют оптимизациям, кешированию регистров CPU и перестановкам программных инструкций.

Другим подходом является использование ключевого слова volatile, которым помечаются необходимые поля класса. Оно заставляет компилятор генерировать барьеры памяти при каждом чтении и записи в переменную, помеченной volatile. Данный подход хорош в том случае, когда у вас один поток, или одни потоки только читают, а другие только записывают. Если же вам необходимо читать и изменять в одном потоке, то стоит воспользоваться оператором lock.

Обе перечисленные выше возможности довольно сложны для понимания, требуют четких знаний в области моделей памяти и оптимизаций на разных уровнях, поэтому используются довольно редко. Да и применять их нужно очень аккуратно и только тогда, когда вы понимаете, что делаете и зачем.

Самый простой и рекомендуемый подход для атомарных операций -- применение класса Interlocked, о котором упоминалось выше. За кулисами также генерируются барьеры памяти, и нам не нужно заботиться о дополнительных блокировках. Данный класс имеет довольно много методов для атомарных операций, таких как увеличение, уменьшение, изменение, изменение со сравнением и т.д.

Collections

Полезно знать, что в пространстве имен System.Collections.Concurrent определено довольно много потокобезопасных коллекций для разных задач. Самые распространенные: BlockingCollection, ConcurrentBag , ConcurrentDictionary<TKey, TValue> , ConcurrentQueue ,

ConcurrentStack .

В большинстве случаев нет смысла в реализации собственной подобной коллекции -- намного проще и разумней использовать готовые протестированные классы.

Асинхронность

Отдельно хотелось бы выделить так называемую асинхронность, которая, с одной стороны, всегда непосредственно связана с запуском дополнительных потоков, а с другой -- с дополнительными вопросами и теорией, на которых тоже стоит остановиться.

Покажем на наглядном примере разницу между синхронным и асинхронным подходами.

Предположим, вы хотите пообедать пиццей в офисе и у вас есть два варианта:

1-й, синхронный вариант: прогуляться пешком в пиццерию, выбрать интересующую вас пиццу, сделать заказ, дождаться, пока его принесут, добраться с пиццей в офис или пообедать непосредственно в пиццерии, после чего вы вернетесь и продолжите работать. В процессе прогулки и ожидания заказа вы будете находиться в режиме ожидания и не сможете заниматься другой полезной работой (для простоты, здесь понимается именно работа в офисе, которая приносит деньги и которую вы не можете выполнять вне рабочего места).

2-й, асинхронный вариант: заказать пиццу по телефону. После заказа вы не заблокированы, можете выполнять полезную работу на рабочем месте, пока ваш заказ обрабатывается и доставляется в офис.

Эволюция

По мере развития .NET Framework было много нововведений и подходов для запуска асинхронных операций. Первым решением для асинхронных задач стал подход под названием APM (Asynchronous Programming Model). Он основан на асинхронных делегатах, которые используют пару методов с именами BeginOperationName и EndOperationName, которые соответственно начинают и завершают асинхронную операцию OperationName. После вызова метода BeginOperationName приложение может продолжить выполнение инструкций в вызывающем потоке, пока асинхронная операция выполняется в другом. Для каждого вызова метода BeginOperationNameв приложении также должен присутствовать вызов метода EndOperationName, чтобы получить результаты операции.

Данный подход можно встретить во множестве технологий и классов, но он чреват усложнением и избыточностью кода.

В версии 2.0 была введена новая модель под названием EAP (Event-based Asynchronous Pattern).

Класс, поддерживающий асинхронную модель, основанную на событиях, будет содержать один или несколько методов MethodNameAsync. Он может отражать синхронные версии, которые выполняют то же действие с текущим потоком. Также в этом классе может содержаться событие MethodNameCompleted и метод MethodNameAsyncCancel (или просто CancelAsync) для отмены операции. Данный подход распространен при работе с сервисами.

В Silverlight применяется для обращения к серверной части, а Ajax по сути представляет из себя реализацию данного подхода. Стоит опасаться длинных цепочек связанных вызовов событий, когда по завершении одной долгосрочной операции в событии ее завершения вызывается следующая, потом еще следующая и так далее. Это чревато дэдлоками и непредвиденными результатами.

Обработка исключений и результаты асинхронной операции доступны только в обработчике события посредством соответствующих свойств параметра: Error и Result.

В .NET Framework 4.0 была введена усовершенствованная модель под названием TAP (Task-based Asynchronous Model), которая основана на задачах. На них также построены TPL и PLINQ, но о них поговорим подробно в следующий раз.

Данная реализация асинхронной модели базируется на типах Task и TaskSystem.Threading.Tasks, которые используются для предоставления произвольных асинхронных операций. TAP -- это рекомендуемый асинхронный шаблон для разработки новых компонентов.

Очень важно понимать разницу между потоком (Thread) и задачей (Task), которые сильно отличаются. Thread (поток) представляет собой инкапсуляцию потока выполнения, в то время как Task является работой (или просто асинхронной операцией), которая может быть выполнена параллельно. Для выполнения задачи используется свободный поток из пула потоков. По завершении работы поток будет возвращен обратно в пул, а пользователь класса получит результат задачи.

Если вам нужно запустить длительную операцию и вы не хотите надолго блокировать один из потоков пула, то можете это сделать при помощи параметра TaskCreationOptions.LongRunning. Создавать и запускать задачи можно разными способами, и часто непонятно, какой из них выбрать. Разница, в основном, лишь в удобстве использования и количестве параметров с настройками, которые доступны в том или ином способе.

В последних версиях фреймворка появились новые возможности на основе все тех же задач, которые упрощают написание асинхронного кода и делают его более читабельным и понятным. Для этого введены новые ключевые слова async и await, которыми помечаются асинхронные методы и их вызовы.

Асинхронный код становится очень похожим на синхронный: мы просто вызываем нужную операцию и весь код, который следует за ее вызовом, автоматически будет завернут в некий «колбек», который вызовется после завершения асинхронной операции.

Также данный подход позволяет обрабатывать исключения в синхронной манере; явно дожидаться завершения операции; определять действия, которые должны быть выполнены, и соответствующие условия. Например, мы можем добавить код, который будет выполнен только в том случае, если в асинхронной операции было сгенерировано исключение. Но не все так просто, даже несмотря на массу информации на эту тему.

Заключение

Как видите, у разработчиков имеется довольно много возможностей для работы с многопоточными приложениями. Важно не только знать теорию, но и уметь применять эффективные подходы для решения конкретных задач. Например, использование класса Threadпочти однозначно говорит о том, что у вас устаревший код в проекте, хотя вероятность возникновения необходимости его использования весьма мала. В обычных ситуациях использование пула всегда оправданно, по понятным причинам.

Использование многопоточности в приложениях с GUI обычно влечет за собой дополнительные ограничения, не забывайте о них!

Также стоит помнить и про другие готовые реализации, такие как потокобезопасные коллекции. Это избавляет от написания дополнительного кода и предотвращает возможные ошибки реализации. Ну и не забывайте про особенности новых ключевых слов.

Литература

1. Макконелл С. Совершенный код. Мастер-класс, СПб.: Питер, 2005. 896 с.

2. Троелсен Э. Язык программирования С# 5.0 и платформа .NET 4.5, М: Издательский дом «Вильямс», 2013. 1312 с.

3. https://habrahabr.ru/company/nixsolutions/blog/260745/

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