Главная страница Библиотека (скачать книги) Скачать софт Введение в программирование Стандарты для C++ Уроки по C# Уроки по Python HTML Веб-дизайн Ассемблер в среде Windows ActiveX Javascript Общее о Линукс Линукс - подробно Линукс - новое Delphi Паскаль для начинающих Турбопаскаль Новости Партнеры Наши предложения Архив новостей |
12. Кодирование параллельных вычисленийРезюмеЕсли ваше приложение использует несколько потоков или процессов, следует минимизировать количество совместно используемых объектов, где это только можно (см. рекомендацию 10), и аккуратно работать с оставшимися. ОбсуждениеРабота с потоками — отдельная большая тема. Данная рекомендация оказалась в книге, потому что эта тема очень важна и требует рассмотрения. К сожалению, одна рекомендация не в силах сделать это полно и корректно, поэтому мы только резюмируем несколько наиболее важных положений и посоветуем обратиться к указанным ниже ссылкам за дополнительной информацией. Среди наиболее важных вопросов, касающихся параллельных вычислений, такие как избежание взаимоблокировок (deadlock), неустойчивых взаимоблокировок (livelock) и условий гонки (race conditions). Стандарт C++ ничего не говорит о потоках. Тем не менее, C++ постоянно и широко применяется для написания кода с интенсивным использованием многопоточности. Если в вашем приложении потоки совместно используют данные, на это следует обратить особое внимание.
При разработке собственного типа, который предназначен для использования в многопоточной программе, вы должны сделать те же две вещи. Во-первых, вы должны гарантировать, что различные потоки могут использовать различные объекты вашего типа без использования блокировок (заметим, что обычно тип с изменяемыми статическими данными не в состоянии обеспечить такую гарантию). Во-вторых, вы должны документировать, что именно должны сделать пользователи для того, чтобы безопасно использовать один и тот же объект в разных потоках. Фундаментальный вопрос проектирования заключается в том, как распределить ответственность за корректное выполнение программы (без условий гонки и взаимоблокировок) между классом и его клиентом. Вот основные возможности.
Заметим, что вызывающий код ничего не должен знать о деталях реализации ваших типов (см. рекомендацию 11). Если ваш тип внутренне использует какие-то методики разделения данных (например, копирование при записи), вы не должны нести ответственность за все возможные вопросы безопасности потоков, но обязаны обеспечить корректность работы вызывающего кода при обычной работе — т.е. тип должен быть безопасен в плане многопоточ-ности в той же мере, как если бы он не использовал методики совместного использования данных. Как упоминалось, все корректно написанные типы должны позволять работу с различными объектами в разных потоках без синхронизации. В частности, если вы разрабатываете библиотеку, предназначенную для широкого использования, вы должны предусмотреть безопасность ваших объектов в многопоточных программах, как описано выше, но при этом без дополнительных накладных расходов при работе в однопо-точной программе. Например, если вы пишете библиотеку, содержащую тип, использующий копирование при записи, и вы должны обеспечить, как минимум, некоторую внутреннюю блокировку, то предпочтительно разработать ее так, чтобы в однопоточном варианте вашей библиотеки ее не было (обычно для этого используются директивы препроцессора #ifdef). Если используется несколько блокировок, то избежать взаимоблокировки можно путем их запроса в одинаковом порядке (освобождение блокировок может выполняться в любом порядке). Одно из решений состоит в запросе блокировок в порядке возрастания адресов в памяти, что обеспечивает удобное, однозначное упорядочение в пределах приложения. 13. Ресурсы должны быть во владении объектовРезюмеНе работайте вручную, если у вас есть мощные инструменты. Идиома C++ "выделение ресурса есть инициализация" (resource acquisition is initialization — RAII) представляет собой мощный инструмент для корректной работы с ресурсами. RAII позволяет компилятору автоматически обеспечить строгую гарантию того, что в других языках надо делать вручную. При выделении ресурса передайте его объекту-владельцу. Никогда не выделяйте несколько ресурсов в одной инструкции. ОбсуждениеСимметрия конструктор/деструктор, обеспечиваемая языком C++, воспроизводит симметрию, присущую парам функций захвата/освобождения ресурса, таким как fopen/fclose, lock/unlock и new/delete. Это делает стековые объекты (или объекты со счетчиком ссылок), в конструкторе которых происходит захват ресурса (а в деструкторе его освобождение), превосходным инструментом для автоматизации управления ресурсами. Автоматизация легко реализуема, элегантна, недорога и по сути безопасна в плане ошибок. Если вы не будете ею пользоваться, то обречете себя на нетривиальную и кропотливую ручную работу по "спариванию" вызовов захвата и освобождения ресурсов, включающую отслеживание всех ветвлений и исключений. Это совершенно неприемлемый путь для C++, который предоставляет возможность автоматизации этой работы при помощи простой в использовании идиомы RAII Когда вы имеете дело с ресурсом, который требует спаривания вызовов функций захвата/освобождения, инкапсулируйте этот ресурс в объект, который выполнит эту работу за вас и освободит ресурс в своем деструкторе. Например, вместо непосредственного вызова пары функций (не членов) OpenPort/ClosePort можно поступить иначе: class Port { public: Port( const string& destination ); // вызов openPort ~Port(); // вызов ClosePort // порты обычно не клонируются, так что запрещаем // копирование и присваивание }; void DoSomething() { Port port1( "serverl:80" ); // ... } // Забыть закрыть порт нельзя - он будет закрыт // автоматически при выходе из области видимости shared_ptr<Port> port2 = /*...*/; // port2 будет закрыт // автоматически, когда будет уничтожен последний // ссылающийся на него объект shared_ptr Вы можете также использовать библиотеки, которые реализуют соответствующий шаблон проектирования. При реализации идиомы RAII следует особо тщательно подходить к вопросу о копирующем конструкторе и присваивании (см. рекомендацию 49): обычно генерируемые компилятором версии этих функций не подходят. Если копирование лишено смысла, копирующий конструктор и оператор присваивания можно явным образом запретить, делая их закрытыми членами и не определяя (см. рекомендацию 53). В противном случае копирующий конструктор дублирует ресурс или использует счетчик ссылок на него, и то же делает и оператор присваивания, при необходимости освободив ресурс, которым объект владел до присваивания. Классической ошибкой является освобождение старого ресурса до того, как успешно дублирован новый (см. рекомендацию 71). Обеспечьте, чтобы все ресурсы принадлежали объектам. Предпочтительно хранить все динамически выделенные ресурсы посредством интеллектуальных, а не обычных, указателей. Кроме того, следует выполнять каждое явное выделение ресурса (например, new) в отдельной инструкции, которая тут же передает ресурс управляющему объекту (например, shared_ptr). В противном случае может возникнуть утечка ресурсов, связанная с тем, что порядок вычисления параметров функции не определен (см. рекомендацию 31). Например: void Fun(shared_ptr Такой код небезопасен. Стандарт C++ предоставляет компилятору большую свободу действий по переупорядочению выражений, которые создают два аргумента функции. В частности, компилятор может чередовать выполнение этих двух выражений: сначала для обоих объектов может быть выполнено выделение памяти (при помощи оператора new), а уже затем будут вызваны два конструктора Widget. Такая последовательность действий может привести к утечке: если один из конструкторов сгенерирует исключение, то память для другого объекта никогда не будет освобождена. Эта тонкая проблема имеет простое решение: следуйте приведенному выше совету и никогда не выделяйте в одной инструкции больше одного ресурса. Следует выполнять каждое явное выделение ресурса (например, new) в отдельной инструкции, которая тут же передает ресурс управляющему объекту (например, shared_ptr), например: shared_ptr<Widget> sp1(new Widget), sp2(new Widget); Fun(sp1, sp2); См. также описание дополнительных преимуществ такого стиля в рекомендации 31. ИсключенияМожно чересчур увлечься интеллектуальными указателями. Обычные указатели вполне подходят для кода, в котором указываемый объект виден только в ограниченном объеме (например, внутри класса — типа указателя на узел дерева в классе Tree, использующийся для навигации по дереву). |
|
Библиотека программиста. 2009. |
|