Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Синхронизация потоков

Подсчет ссылок | Реализация параллельного потока | Менеджер потоков | Взаимодействие с VCL-потоком | Разделяемые данные | Асинхронное взаимодействие | Синхронное взаимодействие |


Читайте также:
  1. А) Для изменения направления потоков продукта
  2. Анализ денежных потоков.
  3. Густота пассажиропотоков по участкам, тыс.чел.
  4. Денежные потоки предприятия как экономическая категория. Основные классификации денежных потоков.
  5. Знаков в них, потоков энергии янь и инь.
  6. Классификация денежных потоков.
  7. КОММУТАЦИЯ ИНФОРМАЦИОННЫХ ПОТОКОВ В СЕТЯХ

Продолжим наш пример и попытаемся найти корректное решение задачи уничтожения объекта потока. Интуитивно можно предположить, что для решения нам потребуется некоторый третейский судья, так как самостоятельно ни приложение, ни поток с задачей не справятся. Таким арбитром может служить объект, известный как "критическая секция". Смысл этого объекта состоит в том, что операционная система гарантирует, что при любом раскладе только один из множества конкурирующих параллельных потоков может попасть внутрь критической секции. Все остальные потоки будут приостановлены операционной системой вплоть до момента, когда поток, захвативший критическую секцию, выйдет из нее. В критической секции можно проверить действительность ссылки, не опасаясь, что она будет нарушена. Это действительно корректное решение, но какой ценой?

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

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

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


Дата добавления: 2015-07-20; просмотров: 44 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
Введение| Потоки и дескрипторы

mybiblioteka.su - 2015-2024 год. (0.007 сек.)