С. Мейерс - Эффективный и современный C++ (1114942), страница 62
Текст из файла (страница 62)
Предположим, например, что у нас есть функция doWork, которая получает функциюфильтрации f i l t e r и максимальное значение maxVal в качестве параметров. ФункцияdoWork выполняет проверку, чтобы убедиться, что все условия, необходимые для ее работы, выполнены, а затем выполняет вычисления со всеми значениями от Одо maxVa l, проходящими через фильтр.
Если фильтрация и определение выполнения условий для функции doWor k требуют большого времени выполнения, может быть разумным выполнитьэти два действия параллельно.Мы бы предпочли воспользоваться советом из раздела 7. 1 и программировать параллельность на основе задач, но предположим, что нам надо установить приоритетпотока, выполняющего фильтрацию. Как пояснялось в разделе 7. 1 , для этого требуется-' Часто их переводят как объединяемое и необъединяемое, но, на наш взгляд, термин подключениелучше отражает смысл происходящего с потоком, связанным с объектом s t d : : thread, при вызо11ефункции join, как и отключение для происходящего при вызове функции detach. - Примеч.
пер.254Глава 7. Параллельные вычислениясистемный дескриптор потока, а он доступен только через API std : : t hread; API задач(т.е. фьючерсы) такой возможности не предоставляет. Поэтому мы работаем с потоками,а не с задачами.Мы могли бы начать с кода наподобие следующего:// См . constexpr в разделе 3 . 9constexpr auto tenМi llion = 1 000000 0 ;11 Возвращает значение , указывающее, бьurи ли вьmолнены11 вычисления; std : : function см. в разделе 2 .
1bool doWork ( std : : function<boo l ( i nt ) > filter,int maxVa l = tenМi l l ion)11 Значения, удовлетворяющие фильтру :std: : vector<int> goodVa l s ;1 1 Заполнение goodVa ls :s t d : : thread t ( [ & filter, maxVal , &goodVa l s ]{for ( auto i = О ; i <= maxVal ; + + i )i f ( filter ( i ) ) goodVa l s . push_back ( i ) ;});11 Используем системный дескриптор потока для11 установки приоритета :auto nht . nat ive_handle ( ) ;=if( condi t i on sAreSa t i sfied () ){/ / Завершаем tt . j oin ( ) ;performComp u ta t i on (goodVals);11 Вычисление вьшоленоreturn true ;11 Вычисление не вьmоленоreturn false;Перед тем как пояснить, почему этот код проблематичен, я замечу, что инициализирующее значение t enMi l l i on в С++ 14 можно сделать более удобочитаемым, воспользовавшись возможностью C++ l 4 использовать апостроф для разделения цифр:constexpr auto tenМill ion=10' 000' 000;/ / С++ 1 4Замечу также, что установка приоритета t после его запуска напоминает забиваниедвери конюшни после того, как лошадь уже убежала.
Лучше начинать с t в приостановленном состоянии (тем самым делая возможным изменение его приоритета до выполнения вычислений}, но я не хочу отвлекать вас этим кодом. Потерпите до раздела 7.5, в немпоказано, как начинать работать с потоками в приостановленном состоянии.7.3.Деnайте std::thread неподкnючаемым на всех путях выпоnнения255Вернемся к функции doWork. Если вызов condi t i on s A re S a t i s f i ed ( ) возвращаетt rue, все в порядке, но если он вернет значение false или сгенерирует исключение, объект t будет подключаемым в момент вызова деструктора при окончании работы doWork.Это приведет к завершению работы программы.Вы можете удивиться, почему деструктор std : : thread ведет себя столь неподобающе. Да просто потому, что два других варианта, описанных далее, еще хуже.•Неявный вызов j oin.•Неявный вызов detach.
В этом случае деструктор s t d : : t hread разрывает связьмежду объектом std : : t hread и его потоком, отключая последний от объекта. Поток продолжает выполняться. Это звучит не менее разумно, чем применение j o in,но проблемы отладки, к которым это может привести, делают этот вариант еще худшим. Например, в функции doWor k локальная переменная goodVa ls захватываетсялямбда-выражением по ссылке. Она также изменяется в лямбда-выражении (с помощью вызова push_bac k) . Предположим теперь, что во время асинхронного выполнения лямбда-выражения вызов condi t i onsAreSat i s f ied ( ) вернул fal se.В таком случае функция doWor k должна завершиться, а ее локальные переменные(включая goodVal s ) должны быть уничтожены.
Ее кадр стека удаляется, и выполнение потока продолжается с точки вызова doWork.В этом случае деструктор std : : thread будет ожидать завершения соответствующего асинхронного потока. Звучит разумно, но может привести к аномалиям производительности, которые будет трудно отследить. Например,было бы нелогичным, чтобы функция doWor k ожидала применения фильтра ко всемзначениям, если вызов cond i t i on sAre S a t i s f i ed ( ) уже вернул значение false.Инструкции после этой точки могут в некоторой иной точке вы полнять вызовыдругих функций, и как м инимум одна из них может занять место в стеке, ранеезанятое кадром стека doWork.
Назовем эту функцию f. Во время работы f лямбдавыражение из doW o r k продолжает асинхронно вы полняться и может вызватьp u s h _b a c k для памяти в стеке, которая ранее использовалась для локальнойпеременной goodV a l s , а теперь принадлежит кадру стека f. Такой вызов можетизмен ить память, использовавшуюся для goodVa l s , а это означает, что с точкизрения f содержимое памяти в ее кадре стека может внезапно измениться! Толькопредставьте себе, что вам придется отлаживать такое.Комитет по стандартизации решил, что последствия уничтожения подключаемого потока достаточно неприятны, чтобы полностью их запретить (указав, что уничтожениеподключаемого потока приводит к завершению программы).Это решение возлагает на вас ответственность за то, что если вы используете объектs t d : : t h read, то должны сделать его неподключаемым на всех путях из области видимости, в которой он определен.
Но охват всех путей может быть весьма сложным. Онвключает как нормальный выход из области видимости, так и такие выходы, как с помощью return, cont inue, break, goto или исключения. Этих путей может быть великоемножество.256Гn ава 7. Параnnеnьные вычисnенияВсякий раз, когда надо выполнить некоторое действие на всех путях, ведущих из блока, естественным подходом является размещение этого действия в деструкторе локального объекта.
Такие объекты известны как объекты RAII, а соответствующие классы классьt RAII. (RAII означает "Resource Acquisition Is Initialization': "захват ресурса естьинициализация': хотя на самом деле речь идет о методе деструкции, а не инициализации.) RАП-классы - распространенное явление в стандартной библиотеке. Примерамиявляются контейнеры STL (деструктор каждого контейнера уничтожает его содержимоеи освобождает память), стандартные интеллектуальные указатели (в разделах 4.
1 -4.3поясняется, что деструктор s t d : : un i que_pt r вызывает удалитель для объекта, на который указывает, а деструкторы s t d : : shared_ptr и std : : weak_ptr уменьшают счетчикиссылок), объекты s t d : : f st ream (их деструкторы закрывают соответствующие файлы)и многое другое. Тем не менее стандартного RAil-клacca для объектов std: : thread нет,вероятно, потому что Комитет по стандартизации, отвергнув и j oin, и detach как варианты по умолчанию, просто не знал, что же должен делать такой класс.К счастью, такой класс несложно написать самостоятельно.
Например, приведенный далее класс позволяет вызывающей функции указать, должна ли быть вызванафункция-член j oi n или det a ch при уничтожении объекта Th readRA I I (объект RAIIдля std : : thread} :class ThreadRAI IpuЫi c :enum class DtorAction { j oin, detach } ;1111ThreadRAI I ( std : : thread&& t , DtorAction а ) 1 1: action ( a ) , t ( s t d : : move ( t ) ) { }11-ThreadRA I I ( }11{if ( t . j oinaЬle ( } }11i f ( actionDtorAction : : j oin) { / /t . j oin ( ) ;else {t . detach ( ) ;==std: : thread& get ( ) { return t ; }private :DtorAction action;std: : thread t ;};См.
emum classв разделе 3 . 4Деструктор дляt вьmолняет аСм. ниже опроверке наподк.лючаемость1 1 См . нижеЯ надеюсь, что этот код самодостаточен и не требует особых пояснений, тем не менееможет быть полезно остановиться на следующих моментах.7.3. Делайте std::thread неподключаемым на всех путях выполнения257•Конструктор принимает только rvalue std : : t hread, поскольку мы хотим перемещать передаваемый объект std : : t hread в объект ThreadRAI I .
(Вспомните, что объекты s t d : : thread не копируются.)•Порядок параметров выбран интуитивно понятным для программиста (сначалауказывается поток, а затем - способ его деструкции), но список инициализациичленов соответствует порядку объявлений членов-данных. Этот порядок размещаетобъект s t d : : thread последним. В этом классе порядок не имеет значения, но в общем случае возможна ситуация, когда инициализация одного члена-данных зависитот другого, а поскольку объекты std : : t hread могут запускаться на выполнение немедленно после их инициализации, объявлять их последними в классе - неплохаяпривычка.
Это гарантирует, что в момент их создания все члены-данные, им предшествующие, уже инициализированы, и, таким образом, асинхронно выполняемыйпоток, соответствующий объекту std : : thread, может безопасно к ним обращаться.•ThreadRAI I предоставляет функцию get, обеспечивающую доступ к соответствующему объекту std : : thre ad. Это аналог функций get, предоставляемых стандартными интеллектуальными указателями и обеспечивающих доступ к их базовымобычным указателям. Предоставление get позволяет избежать необходимости дублировать в классе ThreadRAI I весь интерфейс std : : thread, а также означает, чтообъекты ThreadRAI I могут использоваться в контекстах, где требуются объектыstd : : thread.•Перед тем как деструктор ThreadRAI I вызовет функцию-член объекта t типаstd: : thread, он проверяет, является ли этот объект подключаемым.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
