Интервью с Дмитрием Вьюковым –автором верификатора Relacy RaceDetector (RRD)Автор: Андрей КарповДата: 06.04.2009АннотацияИ...
касательно алгоритмов синхронизации я публикую в группе Scalable Synchronization Algorithms.Так же я разработал и поддержи...
этом RRD позаботится об эффективном исполнении тестов, то есть будет проверено как можнобольше различных чередований (inte...
На каких условиях распространяется RRD?RRD может свободно использоваться для некоммерческой разработки с открытыми исходны...
как из общих описаний мне становилось понятно, что это не то, что мне нужно; и дальшезнакомиться не имело смысла. Поэтому ...
int data;void thread1(){    // простой спин-мьютекс    while (mutex.exchange(1, std::memory_order_acquire))     std::this_...
rl::atomic<node*> head;};void push(stack* s, void* data){    node* n = RL_NEW(node);    n->data($) = data;    node* next =...
}И вот юнит-тест для RRD:// шаблонный параметр "2" задаёт кол-во потоков в тестеstruct test : rl::test_suite<test, 2>{    ...
iteration: 2execution history:[0] 1: [BEFORE BEGIN][1] 1: <0023DEA0> atomic store, value=00000000,(prev value=00000000), o...
[16] 1: <0023CB78> atomic store, value=0023CE80,(prev value=00000000), order=relaxed, in push, main.cpp(39)[17] 0: <0023CE...
программирования разработчиков. Но VivaMP будет так же полезен и более опытнымразработчикам, так как никто не застрахован ...
получается, а что нет, пробуйте ещё; выдвигайте гипотезы - проверяйте их, выдвигайте новыегипотезы и так далее. Только пра...
Upcoming SlideShare
Loading in …5
×

Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)

446 views

Published on

Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.

Published in: Technology, Sports
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
446
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)

  1. 1. Интервью с Дмитрием Вьюковым –автором верификатора Relacy RaceDetector (RRD)Автор: Андрей КарповДата: 06.04.2009АннотацияИнтервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) дляверификации параллельных приложений. В статье вы узнаете об истории создания RRD, егоосновных возможностях, а также о некоторых других аналогичных инструментах и их отличии отRRD.ВведениеВашему вниманию предлагается интервью с автором верификатора Relacy Race Detector (RRD) длятестирования многопоточных алгоритмов. В интервью обсуждаются перспективы использованияRRD и других инструментов для проверки параллельных приложений и смежные темы.Вопросы задает (вопросы будут выделены жирным текстом):Карпов Андрей Николаевич. Один из основателей компании "Системы программнойверификации", занимается разработкой инструментов для статического анализа исходного кода.Участвует в развитии инструментов Viva64 и VivaMP для тестирования 64-битных и параллельныхприложений. Поддерживает открытую библиотеку VivaCore, предназначенную для разбора(парсинга) Си/Си++ кода.На вопросы отвечает:Вьюков Дмитрий Сергеевич. Разработчик высокопроизводительного программного обеспеченияна Си/Си++ в области клиент/серверных систем и сетевых серверов. В свободное времяувлекается разработкой инновационных алгоритмов синхронизации, разработкой моделейпрограммирования для многоядерных процессоров и систем верификации многопоточного кода.Автор инструмента Relacy Race Detector (RRD).Текст интервьюЗдравствуйте, Дмитрий. Расскажите немного о себе, чемзанимаетесь и в каких проектах участвуете?В меру своих сил я занимаюсь всем, что связано с многопоточностью и параллелизмом:масштабируемыми алгоритмами синхронизации, моделями программирования длямногоядерных процессоров, верификацией многопоточного кода и так далее. Свои разработки
  2. 2. касательно алгоритмов синхронизации я публикую в группе Scalable Synchronization Algorithms.Так же я разработал и поддерживаю инструмент верификации многопоточного кода Relacy RaceDetector (RRD).Что подтолкнуло Вас к созданию верификатора Relacy RaceDetector?RRD появился достаточно спонтанно. Предпосылок для его создания было три.Первая - я занимаюсь разработкой алгоритмов синхронизации, а тестирование и локализацияошибок в них - очень и очень серьёзная проблема: ошибки проявляются очень редко или вообщене проявляются на некоторых компьютерах (допустим на компьютерах с менее чем 4-мяпроцессорами, или на компьютерах с некоторой версией операционной системы). А если ошибкавсё-таки регулярно проявляется, то часто бывает очень сложно понять истинную первопричинуошибки (в какой момент и что именно начинает идти "не так"). Это породило мысль, что неплохобыло бы иметь какие-то "инструменты" для решения проблемы.Вторая предпосылка - за время работы с алгоритмами синхронизации накопился некоторый багажприёмов, которые я применял для тестирования и локализации ошибок. Один из основных - этовставка в код программы большого количества примерно таких строчек:if ((rand() % 1000) == 0) Sleep (rand() % 10);и последующее стресс-тестирование работы программы. Этот приём позволяет добитьсявыполнения значительно большего количества различных чередований (interleaving) потоков.Собственно это, по большому счёту, и является основным принципом работы RRD.Третьей предпосылкой явилось то, что в какой-то момент я, наконец, понял, как можно собратьвсе мои приёмы в автоматический инструмент тестирования, как можно простым способомпроводить необходимое инструментирование программы, и как при этом можно обеспечитьвысокую эффективность работы инструмента. Дальше было дело техники - первый рабочийпрототип (который реально обнаружил одну специально внесённую ошибку в простой алгоритм)появился в тот же день ближе к ночи. Хотя, конечно, доведение RRD до более-менее пригодногодля реальной работы вида заняло значительно больше времени.Расскажите, пожалуйста, о RRD более подробно. Какие принципы иалгоритмы лежат в его основе? В каких областях его применениенаиболее перспективно?RRD является средством динамической верификации без запоминания состояний. Онпредназначен, прежде всего, для тестирования многопоточных алгоритмов (алгоритмовсинхронизации, многопоточных структур данных и так далее). Для пользователя работа с RRDвыглядит примерно следующим образом. Вначале реализуется тестируемый алгоритм.Реализация может быть выражена через примитивы синхронизации C++09, POSIX threads(pthread), Win32 API, C#/.NET, Java. Однако необходимо использовать указанные API не напрямую,а через "обёртки", предоставляемые RRD; синтаксис практически идентичен, однако имеютсянекоторые отличия. Когда тестируемый алгоритм реализован, необходимо реализовать один илинесколько юнит-тестов (unit test) для алгоритма. Далее можно запускать их на исполнение, при
  3. 3. этом RRD позаботится об эффективном исполнении тестов, то есть будет проверено как можнобольше различных чередований (interleaving) потоков. Во время исполнения каждогочередования RRD будет делать множество различных проверок корректности алгоритма, включаякак пользовательские утверждения (asserts) и инварианты (invariants), так и базовые встроенныепроверки - гонки (data races), обращения к освобожденной памяти, двойные освобожденияпамяти, утечки памяти, взаимные блокировки (deadlocks), активные блокировки (livelocks),некорректные использования API (например, рекурсивный захват нерекурсивного мьютекса), идругие. При обнаружении ошибки RRD выведет подробную историю исполнения, которая привелак ошибке. Имея на руках такую историю, локализация ошибки становится делом техники (историясодержит такие детали как отклонения от последовательно согласованного (sequentiallyconsistent) порядка, инстансы ABA проблемы, ложные пробуждения на условных переменных(condition variable) и т.д.).Большое количество встроенных проверок и пристрастность, с которой RRD их проводит,позволяют во многих случаях не делать в тесте вообще никаких пользовательских проверок.Например, если мы тестируем reader-writer мьютекс, то достаточно лишь создать несколькопотоков, которые будут захватывать мьютекс на чтение и считывать какую-то переменную, инесколько потоков, которые захватывают мьютекс для записи и изменяют эту же переменную.Если алгоритм мьютекса не обеспечивает взаимного исключения, то автоматически будетобнаружена гонка на защищаемой переменной; если алгоритм может входить во взаимнуюблокировку или активную блокировку, то RRD тоже обнаруживает это автоматически. Однако еслимы тестируем очередь типа производитель-потребитель (producer-consumer), и очередь должнаобеспечивать FIFO порядок сообщений, то такую проверку придётся запрограммировать вручную.Теперь немного о внутреннем устройстве RRD, и об используемых алгоритмах. RRDинструментирует все обращения к переменным, примитивам синхронизации и API вызовам. Этодаёт возможность встроить в них все необходимые проверки, а так же возможность полностьюуправлять переключением потоков. RRD содержит 3 планировщика потоков (выбор планировщикапроизводится при запуске теста).Самый простой планировщик - это так называемый случайный планировщик (random scheduler),после каждого элементарного действия программы (обращении к переменной, примитивусинхронизации, API вызову) планировщик выбирает случайный поток и переключает управлениена него. Этот планировщик хорош для первоначального тестирования алгоритма, т.к. он не даётисчерпывающей проверки, но зато работает очень быстро.Второй планировщик производит полный систематический перебор всех возможных чередованийпотоков (full search scheduler), однако его недостаток в очень длительном времени верификации,на практике его целесообразно применять только для небольших тестов.Последний, третий, планировщик самый интересный и полезный - это так называемыйпланировщик с ограничением на количество переключений потоков (context bound scheduler). Онпроизводит систематический перебор чередования потоков, однако при этом проверяет толькочередования, в которых общее количество добровольных переключений потоков не большенекоторого заданного числа. За счёт этого он даёт очень хороший компромисс между качествомпроверки и временем работы. Так же следует отметить, что все планировщики являютсясправедливыми (fair), это даёт возможность тестировать формально не терминирующиеалгоритмы, т.е. алгоритмы, содержащие циклы, которые могут повторяться потенциальнонеограниченное число раз.
  4. 4. На каких условиях распространяется RRD?RRD может свободно использоваться для некоммерческой разработки с открытыми исходнымикодами, для образовательных целей, для академических разработок с непатентуемымирезультатами, а так же для персонального некоммерческого использования. Для всех остальныхприменений RRD является платным. Хотя возможно рассмотрение частных случаев; например, яимел некоторые предварительные беседы касательно предоставления специальных лицензийдля разработки ядра Linux (там есть некоторые скользкие моменты, касающиеся патентованныхалгоритмов и коммерциализации), а так же для разработки Intel Threading Building Blocks (которыйраспространяется под двойной лицензией, одна из которых коммерческая).Вы можете порекомендовать какие-то дополнительные ресурсы,связанные с RRD? Где можно скачать RRD?Основной ресурс, посвященный RRD расположен по адресу:http://www.viva64.com/go.php?url=194Там можно скачать последнюю версию библиотеки, найти некоторые материалы по RRD, а так жезадавать вопросы. Дистрибутив RRD включает ряд примеров, которые могут помочь освоить RRD.Вы, наверное, знакомы со многими другими верификаторамипараллельных приложений. Действительно ли не один из них нереализует диагностики, которые позволяет производить RRD? Вчем их отличие от RRD?Да, конечно, до создания RRD я смотрел на множество средств верификации (Intel Thread Checker,Chord, Zing, Spin, RacerX, CheckFence, Sober, Coverity Thread Analyzer, CHESS, KISS, PreFast, Prefix,FxCop) в надежде найти то, что нужно для моих целей. Однако большинство инструментоврассчитаны, так сказать, на разработчиков конечных прикладных программ, а не на разработчиковалгоритмов синхронизации и библиотек поддержки параллелизма. Ни один из инструментов недаёт того уровня детализации и точности моделирования свободного доступа к памяти (RelaxedMemory Order) [*], который был необходим мне. Образно, если упомянутые средства могутверифицировать программу, использующую OpenMP, то RRD может верифицировать самуреализацию OpenMP.[*] Примечание. Свободный доступ к памяти (Relaxed Memory Order, RMO) - метод работы спамятью, когда процессор использует все средства кэширования и динамическогопереупорядочения команд, и не пытается обеспечить никаких требований к упорядоченностивыборки и сохранению операндов в основной памяти. Иногда такой режим называют"расслабленная модель памяти".Вы назвали множество различных инструментов. Не могли бы Вывкратце рассказать о них? Многие читатели, вероятно, даже неслышали о большинстве этих инструментов.Сразу оговорюсь, что с большинством инструментов я не знакомился практически (установка,запуск примеров, применение в собственных проектах). Я знакомился с ними поверхностно, так
  5. 5. как из общих описаний мне становилось понятно, что это не то, что мне нужно; и дальшезнакомиться не имело смысла. Поэтому я, наверное, не смогу рассказать много интересного дляконечных пользователей, но тем не менее...Могу рассказать про инструмент Spin, который несколько приближается по свойствам к RRD, и язнаю, что он использовался для верификации некоторых алгоритмов синхронизации для ядраLinux и для Threading Building Blocks. Spin - это, наверное, самый старый и основательныйинструмент такого рода, его корни уходят в начало 80-ых годов, по нему написан ряд книг, и, чтоочень приятно, он активно развивается и по сей день. Spin включает множество вариантовпроверки - динамическая проверка с запоминанием состояний, без запоминания, полнаяпроверка модели программы, не полная проверка модели программы (для очень большихпрограмм) и так дадее, всего и не перечесть. Компилятор Promela (язык, используемый Spin) иверификатор (Protocol ANalyser, pan в терминологии Spin) имеют множество ключей,управляющих различными аспектами работы (режим проверки, степень детализации вывода,лимит памяти и так далее), так же имеется несколько GUI оболочек. Одним словом, если вампонадобится что-то особенное, скорее всего, это уже есть в Spin.Сам процесс работы со Spin схож с RRD - описывается тест на специальном языке Promela (aPRocess MEta LAnguage), далее компилируете его, на выходе получается исходный файл на языкеС, который надо скомпилировать С компилятором, что бы получить верификатор. Далеезапускаете верификатор, и при обнаружении ошибки он создаёт файл с подробным описаниемошибки и истории выполнения. Потом из этого файла можно сгенерировать Postscript файл дляпросмотра, или использовать для "проигрывания" истории выполнения. Как видно процессработы со Spin несколько сложнее, чем с RRD, ну что ж, статус обязывает :).Возникает закономерный вопрос - чем же меня не устроил Spin? Во-первых, это специальный языкPromela для описания тестов; с одной стороны это кажется не таким уж и принципиальныммоментом, но с другой стороны я иногда ловлю себя на том, что мне лень делать даже томинимальное инструментирование кода, которое требуется для RRD. Да и переписываяпрограмму вручную на другой язык, мы рискуем протестировать не совсем то, что хотели. Во-вторых, это последовательно согласованная (sequentially consistent) модель памяти; тут уженичего не сказать в защиту Spin - поддержка свободного доступа к памяти ("расслабленноймодели памяти") просто необходима для верификатора алгоритмов синхронизации. В-третьих, этоотсутствие встроенной поддержки для таких специфических вещей как вызовы Win32 APIWaitForMultipleObjects() или SignalObjectAndWait(), или ложные пробуждения на condition variablePOSIX, или ожидания с таймаутами, и так далее. Совокупность этих факторов в итоге заставиламеня отвернуться от Spin.Тем не менее, ещё раз подчеркну, что инструмент очень и очень достойный. Основной сайтпроекта - http://spinroot.com/ .Вы можете привести примеры кода, чтобы нагляднее пояснитьпринципы работы RRD и его отличие от других инструментов?Вот простой пример, в котором реализуется взаимное исключение на основе спин-мьютекса(первый пример я приведу в синтаксисе C++09, а второй в синтаксисе RRD, что бы показатьразличия):std::atomic<int> mutex;
  6. 6. int data;void thread1(){ // простой спин-мьютекс while (mutex.exchange(1, std::memory_order_acquire)) std::this_thread::yield(); data = 1; mutex.store(0, std::memory_order_release);}void thread2(){ // простой спин-мьютекс while (mutex.exchange(1, std::memory_order_acquire)) std::this_thread::yield(); data = 2; mutex.store(0, std::memory_order_relaxed);}В этом примере содержится так называемая гонка второго типа (data race type 2). Гонки типа 2характеризуются тем, что конфликтующие доступы к проблемной переменной не являютсясмежными ни в одном чередовании потоков; тем не менее, они конфликтуют из-за возможногопереупорядочивания обращений к памяти при свободном доступе. RRD обнаружит эту гонку ипокажет в результирующей истории исполнения какие именно переупорядочивания имели место.Вот несколько более сложный пример - lock-free stack (уже записанный в синтаксисе RRD;основное пространство имён, используемое RRD - "rl", так же обратите внимание на требуемоеинструментирование кода в виде "($)"):struct node{ rl::atomic<node*> next; rl::var<void*> data;};struct stack{
  7. 7. rl::atomic<node*> head;};void push(stack* s, void* data){ node* n = RL_NEW(node); n->data($) = data; node* next = s->head($).load(rl::memory_order_relaxed); for (;;) { n->next($).store(next, rl::memory_order_relaxed); if (s->head($).compare_exchange_weak( next, n, rl::memory_order_release)) break; }}void* pop(stack* s){ node* n = s->head($).load(rl::memory_order_relaxed); for (;;) { if (0 == n) return 0; node* next = n->next($).load(rl::memory_order_relaxed); if (s->head($).compare_exchange_weak( n, next, rl::memory_order_acquire)) break; } void* data = n->data($); RL_DELETE(n); return data;
  8. 8. }И вот юнит-тест для RRD:// шаблонный параметр "2" задаёт кол-во потоков в тестеstruct test : rl::test_suite<test, 2>{ stack s; // выполняется в одном потоке // перед исполнением основной функции потоков void before() { s.head($) = 0; } // основная функция потоков void thread(unsigned /*thread_index*/) { push(&s, (void*)1); void* data = pop(&s); RL_ASSERT(data == (void*)1); }};int main(){ rl::simulate<test>();}Если мы запустим программу, то увидим следующий вывод (я убрал историю выполненияотдельных потоков; первая цифра в строчке является глобальным порядковым номеромоперации - для сопоставления с историей выполнения отдельных потоков, вторая цифра - номерпотока):struct testACCESS TO FREED MEMORY (access to freed memory)
  9. 9. iteration: 2execution history:[0] 1: [BEFORE BEGIN][1] 1: <0023DEA0> atomic store, value=00000000,(prev value=00000000), order=seq_cst, in test::before, main.cpp(70)[2] 1: [BEFORE END][3] 1: memory allocation: addr=0023CB78, size=52,in push, main.cpp(34)[4] 1: <0023CB9C> store, value=00000001, in push, main.cpp(35)[5] 1: <0023DEA0> atomic load, value=00000000, order=relaxed,in push, main.cpp(36)[6] 0: memory allocation: addr=0023CE80, size=52,in push, main.cpp(34)[7] 0: <0023CEA4> store, value=00000001, in push, main.cpp(35)[8] 1: <0023CB78> atomic store, value=00000000, (prev value=00000000),order=relaxed, in push, main.cpp(39)[9] 0: <0023DEA0> atomic load, value=00000000, order=relaxed,in push, main.cpp(36)[10] 0: <0023CE80> atomic store, value=00000000,(prev value=00000000), order=relaxed, in push, main.cpp(39)[11] 1: <0023DEA0> CAS fail [SPURIOUSLY] orig=00000000,cmp=00000000, xchg=0023CB78, order=release, in push, main.cpp(40)[12] 0: <0023DEA0> CAS succ orig=00000000, cmp=00000000,xchg=0023CE80, order=release, in push, main.cpp(40)[13] 1: <0023CB78> atomic store, value=00000000,(prev value=00000000), order=relaxed, in push, main.cpp(39)[14] 0: <0023DEA0> atomic load, value=0023CE80, order=relaxed,in pop, main.cpp(47)[15] 1: <0023DEA0> CAS fail orig=0023CE80, cmp=00000000,xchg=0023CB78, order=release, in push, main.cpp(40)
  10. 10. [16] 1: <0023CB78> atomic store, value=0023CE80,(prev value=00000000), order=relaxed, in push, main.cpp(39)[17] 0: <0023CE80> atomic load, value=00000000, order=relaxed,in pop, main.cpp(52)[18] 1: <0023DEA0> CAS succ orig=0023CE80, cmp=0023CE80,xchg=0023CB78, order=release, in push, main.cpp(40)[19] 1: <0023DEA0> atomic load, value=0023CB78, order=relaxed,in pop, main.cpp(47)[20] 0: <0023DEA0> CAS fail orig=0023CB78, cmp=0023CE80,xchg=00000000, order=acquire, in pop, main.cpp(53)[21] 1: <0023CB78> atomic load, value=0023CE80, order=relaxed,in pop, main.cpp(52)[22] 1: <0023DEA0> CAS succ orig=0023CB78, cmp=0023CB78,xchg=0023CE80, order=acquire, in pop, main.cpp(53)[23] 1: <0023CB9C> load, value=00000001, in pop, main.cpp(56)[24] 1: memory deallocation: addr=0023CB78, in pop, main.cpp(57)[25] 0: ACCESS TO FREED MEMORY (access to freed memory),in pop, main.cpp(52)Из вывода мы видим, что при проверке второго чередования потоков RRD обнаружил обращениек освобожденной памяти. Из анализа истории можно понять, что поток 1 снимает элемент состека и освобождает его, после этого поток 0 обращается к этому элементу.Какое Ваше мнение о новом инструменте VivaMP? Насколько Высчитаете его сейчас актуальным, ведь технология OpenMP покаиспользуется достаточно малым количеством разработчиков?Я думаю, что тут Вы немного лукавите, говоря, что OpenMP используется малым количествомразработчиком. Конечно, всё относительно; но я думаю, что буду недалек от истины, сказав, чтоOpenMP - самая распространённая в промышленном коде библиотека поддержки параллелизма.Во-первых, это - относительно старое и проверенное средство, поддерживаемое множествомкоммерческих и некоммерческих организаций, с множеством независимых реализаций. Во-вторых, оно достаточно простое и хорошо решает свою задачу.Ну и естественно я, как разработчик собственного средства верификации многопоточного кода,считаю такие инструменты очень актуальными и необходимыми; особенно сейчас, когда укаждого из нас на рабочем столе стоит компьютер с многоядерным процессором. Исходя из этихдвух вещей, VivaMP - просто незаменимое средство для начинающих в области параллельного
  11. 11. программирования разработчиков. Но VivaMP будет так же полезен и более опытнымразработчикам, так как никто не застрахован как от "глупых" ошибок (невнимательность, copy-paste), так и от "умных". А VivaMP всегда будет "прикрывать тыл" своей беспристрастностью ивычислительной мощью. Я знаю не мало примеров, когда многопоточный код, разработанный втом числе и экспертами, и просмотренный не одной парой глаз, работал годами, но потом в нёмвсё же обнаруживались серьёзные ошибки, которые приводили к зависаниям и падениям.Значительная часть этих ошибок была или могла бы быть обнаружена средствами верификации,такими как VivaMP.Касательно технической стороны вопроса, VivaMP - это средство статической верификации. И чтомне очень нравится в статической верификации так это то, что не нужно писать юнит-тесты;инструмент проверяет целевой код сам по себе. И вопрос даже не столько в необходимостинаписать некоторый объём дополнительного кода, сколько в том, что это - опять же человеческийфактор. Разработчик должен определить, какие именно тесты необходимы, как именно онидолжны работать и так далее; и качество проверки напрямую будет зависеть от качества юнит-тестов. При использовании VivaMP такой проблемы нет, есть только проверяемый код иинструмент. Я считаю, что это очень сильное свойство.Вы проявили интерес к открытой библиотеки анализа кодаVivaCore, созданной нашей компании ООО "Системы программнойверификации". С чем это связано и может ли библиотека помочь вусовершенствовании RRD?Идея была в устранении необходимости ручного инструментирования кода. Т.е. написатьсобственный препроцессор кода на основе библиотеки VivaCore, что бы он вставлял в нужныеместа все эти пресловутые "($)", а пользователь мог тестировать непосредственно свой "боевой"код. Однако после предпроектных исследований выяснилось, что это потребует затрат достаточносущественных ресурсов, поэтому от этой идеи, к сожалению, пришлось отказаться.Как дальше Вы планируете развивать RRD?Планов у меня всегда много :). На сайте RRD можно видеть TODO/Feature List, в котором яотражаю свои планы и идеи касательно дальнейшего развития RRD. Из наиболее существенных иинтересных доработок можно отметить поддержку локального хранилища потоков (TSS/TLS) собёртками для POSIX и Win32, поддержку UNIX сигналов и различных типов аппаратныхпрерываний, оптимизация алгоритма полного перебора состояний программы (partial-orderreductions) и распараллеливание работы библиотеки, периодическое сохранение состояния вконтрольных точках, определение "мёртвого" (не тестируемого) кода, моделированиехарактеристик программы, касающихся производительности и масштабируемости. Однако вданный момент развитие библиотеки, так сказать, demand-driven, т.е. движется нуждамипользователей. Поэтому буду рад услышать отзывы, мысли и идеи читателей по этому поводу.Что бы вы хотели сказать в заключение тем нашим читателям,которые начинают осваивать параллельные технологии?Про параллельные технологии можно сказать всё то же, что и про любую другую новуютехнологию - больше экспериментируйте; пробуйте решать простые задачи - смотрите что
  12. 12. получается, а что нет, пробуйте ещё; выдвигайте гипотезы - проверяйте их, выдвигайте новыегипотезы и так далее. Только практика и обратная связь может сделать Вас - профессионалом. Нуи, конечно, "не брезгайте" средствами автоматической верификации кода, это как эксперт всегдастоящий за спиной и приглядывающий за вами. Естественно можно обойтись и без таких средств,ну уж как минимум они сэкономят вам массу времени.Большое спасибо за интервью, интересные и содержательныеответы.Спасибо. Желаю Вам и нашим читателям успехов в их разработках.ЗаключениеЕще раз хотим поблагодарить Дмитрия за интересную беседу и рассказ об инструментахверификации параллельных приложений. В конце статьи в библиографическом списке читателимогут познакомиться со списком ресурсов посвященных RRD и ряду других инструментов схожейнаправленности.Библиографический список 1. Anthony Williams. Petersons lock with C++0x atomics. http://www.viva64.com/go.php?url=192 2. Q&A with a TBB Junkie. http://www.viva64.com/go.php?url=193 3. Relacy Race Detector. http://www.viva64.com/go.php?url=194 4. Scalable Synchronization Algorithms. http://www.viva64.com/go.php?url=195 5. Spin - Formal Verification. http://www.viva64.com/go.php?url=196 6. Евгений Рыжков. VivaMP - инструмент для OpenMP. http://www.viva64.com/art-3-1- 1671511269.html 7. Андрей Карпов. Тестирование параллельных программ. http://www.viva64.com/art-3-1- 65331121.html. 8. Открытая библиотека VivaCore для разбора и анализа Си/Си++ кода. http://www.viva64.com/ru/vivacore-library/.

×