Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску
Для обсуждения условий гонки в Википедии см. Конфликт редактирования .
Состояние гонки в логической цепи. Здесь ∆ t 1 и ∆ t 2 представляют собой задержки распространения логических элементов. Когда входное значение A изменяется с низкого на высокое, схема выводит короткий всплеск длительности (∆ t 1 + ∆ t 2 ) - ∆ t 2 = ∆ t 1 .

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

Термин « состояние гонки» уже использовался к 1954 году, например, в докторской диссертации Дэвида А. Хаффмана «Синтез схем последовательного переключения». [1]

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

В электронике [ править ]

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

Рассмотрим, например, двухвходовой логический элемент И, на один вход которого подается логический сигнал А, а на другом - отрицание НЕ А. Теоретически результат (А И НЕ А) никогда не должен быть правдой. Если, однако, изменения в значении A распространяются на второй вход дольше, чем на первый, когда A изменяется с false на true, то наступает короткий период, в течение которого оба входа являются истинными, и поэтому выход логического элемента также будет истинным. . [2]

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

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

Критические и некритические формы [ править ]

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

Некритическое состояние гонки возникает , когда порядок , в котором изменяются внутренние переменные не определяет возможное состояние , что состояние машины будет в конечном итоге в.

Статические, динамические и основные формы [ править ]

Состояние статической гонки возникает, когда сигнал и его дополнение объединяются.

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

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

В программном обеспечении [ править ]

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

Гонка данных - это тип состояния гонки. Гонки данных - важные части различных формальных моделей памяти . Модель памяти, определенная в стандартах C11 и C ++ 11, указывает, что программа C или C ++, содержащая гонку данных, имеет неопределенное поведение . [3] [4]

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

Пример [ править ]

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

Поток 1Поток 2Целочисленное значение
0
прочитать значение←0
увеличить стоимость0
написать ответ→1
прочитать значение←1
увеличить стоимость1
написать ответ→2

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

Поток 1Поток 2Целочисленное значение
0
прочитать значение←0
прочитать значение←0
увеличить стоимость0
увеличить стоимость0
написать ответ→1
написать ответ→1

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

Гонка за данными [ править ]

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

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

На многих платформах для одновременного доступа предусмотрены специальные операции с памятью; в таких случаях обычно одновременный доступ с использованием этих специальных операций является безопасным, но одновременный доступ с использованием других операций с памятью опасен. Иногда такие специальные операции (которые безопасны для одновременного доступа) называются атомарными операциями или операциями синхронизации , тогда как обычные операции (которые небезопасны для одновременного доступа) называются операциями с данными . Вероятно, поэтому термин « гонка данных» ; на многих платформах, где есть состояние гонки, включающее только операции синхронизации , такая гонка может быть недетерминированной, но в остальном безопасна; но данные race может привести к повреждению памяти или неопределенному поведению.

Примеры определений гонок данных в конкретных моделях параллелизма [ править ]

Точное определение гонки данных различается в разных формальных моделях параллелизма. Это важно, потому что параллельное поведение часто не интуитивно понятно, и поэтому иногда применяется формальное рассуждение.

Стандарт C ++ в проекте N4296 (2014-11-19)] определяет гонку данных следующим образом в разделе 1.10.23 (стр. 14) [6]

Два действия потенциально могут быть одновременными, если

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

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

Части этого определения, относящиеся к обработчикам сигналов, идиосинкразичны для C ++ и не типичны для определений гонки данных .

В статье « Обнаружение гонки данных в системах со слабой памятью» [7] дается другое определение:

«две операции с памятью конфликтуют, если они обращаются к одному и тому же месту и хотя бы одна из них является операцией записи ...» Две операции с памятью, x и y, при последовательном согласованном выполнении образуют гонку 〈x, y〉, если и только если x и y конфликтуют, и они не упорядочиваются отношением исполнения hb1. Гонка 〈x, y〉 является гонкой данных, если хотя бы одно из x или y является операцией с данными.

Здесь у нас есть две операции с памятью, обращающиеся к одному и тому же месту, одна из которых - запись.

Отношение hb1 определено в другом месте статьи и является примером типичного отношения «произошло до »; интуитивно, если мы можем доказать, что мы находимся в ситуации, когда одна операция памяти X гарантированно будет выполнена до завершения до начала другой операции памяти Y, тогда мы скажем, что «X происходит до Y». Если ни «X происходит до Y», ни «Y происходит до X», то мы говорим, что X и Y «не упорядочены отношением hb1». Таким образом, предложение «... и они не упорядочены отношением исполнения hb1» можно интуитивно перевести как «... и X и Y потенциально параллельны».

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

Спецификация языка Java [8] дает другое определение:

Два доступа (чтение или запись) к одной и той же переменной называются конфликтующими, если хотя бы один из обращений является записью ... Когда программа содержит два конфликтующих доступа (§17.4.1), которые не упорядочены Отношение происходит до того, как говорят, что оно содержит гонку данных ... гонка данных не может вызвать некорректное поведение, такое как возврат неправильной длины для массива.

Критическое различие между подходом C ++ и подходом Java состоит в том, что в C ++ гонка данных - это неопределенное поведение, тогда как в Java гонка данных просто влияет на «межпоточные действия». [8] Это означает, что в C ++ попытка выполнить программу, содержащую гонку данных, может (при соблюдении спецификации) привести к сбою или может показывать небезопасное или странное поведение, тогда как в Java попытка выполнить программу, содержащую данные race может вызвать нежелательное поведение параллелизма, но в остальном (при условии, что реализация соответствует спецификации) безопасна.

SC для DRF [ править ]

Важным аспектом гонок данных является то, что в некоторых контекстах программа, свободная от гонок данных, гарантированно выполняется последовательно согласованным образом, что значительно упрощает рассуждения о параллельном поведении программы. Говорят, что формальные модели памяти, которые обеспечивают такую ​​гарантию, демонстрируют свойство «SC для DRF» (Последовательная согласованность для свободы от гонки данных). Было сказано, что этот подход недавно достиг консенсуса (предположительно, по сравнению с подходами, которые гарантируют последовательную согласованность во всех случаях, или подходами, которые не гарантируют его вообще). [9]

Например, в Java эта гарантия прямо указывается: [8]

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

Если программа правильно синхронизирована, то все выполнения программы будут выглядеть последовательно согласованными (§17.4.3).

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

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

Напротив, черновик спецификации C ++ не требует напрямую SC для свойства DRF, а просто отмечает, что существует теорема, обеспечивающая его:

[Примечание: можно показать, что программы, которые правильно используют мьютексы и операции memory_order_seq_cst для предотвращения всех гонок данных и не используют никаких других операций синхронизации, ведут себя так, как если бы операции, выполняемые их составляющими потоками, просто чередовались, с вычислением каждого значения объекта от последнего побочного эффекта этого объекта в этом чередовании. Обычно это называют «последовательной согласованностью». Однако это относится только к программам без гонки данных, а программы без гонки данных не могут наблюдать большинство программных преобразований, которые не изменяют семантику однопоточной программы. Фактически, большинство однопоточных программных преобразований по-прежнему разрешены, поскольку любая программа, которая в результате ведет себя иначе, должна выполнять неопределенную операцию.

Обратите внимание, что проект спецификации C ++ допускает возможность программ, которые действительны, но используют операции синхронизации с memory_order, отличным от memory_order_seq_cst, и в этом случае результатом может быть программа, которая является правильной, но для которой не предоставляется гарантия последовательной согласованности. Другими словами, в C ++ некоторые правильные программы не являются последовательными. Считается, что этот подход дает программистам на C ++ свободу выбора более быстрого выполнения программы за счет отказа от простоты рассуждений о своей программе. [9]

Существуют различные теоремы, часто предоставляемые в форме моделей памяти, которые обеспечивают SC для DRF-гарантий в различных контекстах. Предпосылки этих теорем обычно накладывают ограничения как на модель памяти (и, следовательно, на реализацию), так и на программиста; то есть, как правило, это тот случай, когда есть программы, которые не соответствуют предпосылкам теоремы и которые не могут гарантировать последовательное последовательное выполнение.

Модель памяти DRF1 [10] предоставляет SC для DRF и позволяет оптимизировать WO (слабое упорядочение), RCsc (согласованность выпуска с последовательно согласованными специальными операциями), модель памяти VAX и модели памяти без гонки данных-0. Модель памяти PLpc [11] предоставляет SC для DRF и позволяет оптимизировать модели TSO ( общий порядок хранения ), PSO, PC ( согласованность процессора ) и RCpc (согласованность выпуска со специальными операциями согласованности процессора). DRFrlx [12] дает набросок SC для теоремы DRF в присутствии релаксированной атомики.

Компьютерная безопасность [ править ]

Многие условия гонки программного обеспечения связаны с последствиями для компьютерной безопасности . Состояние гонки позволяет злоумышленнику, имеющему доступ к общему ресурсу, вызвать сбой в работе других участников, использующих этот ресурс, что приводит к таким последствиям, как отказ в обслуживании [13] и повышение привилегий . [14] [15]

Особый вид состояния гонки включает проверку предиката (например, аутентификацию ), затем действие на предикат, при этом состояние может изменяться между временем проверки и временем использования . Когда этот вид ошибки существует в чувствительном к безопасности коде, создается уязвимость безопасности, называемая ошибкой времени проверки до времени использования ( TOCTTOU ).

Условия гонки также намеренно используются для создания аппаратных генераторов случайных чисел и физически неклонируемых функций . [16] [ необходима цитата ] PUF могут быть созданы путем проектирования топологий схемы с идентичными путями к узлу и использования производственных вариаций для случайного определения того, какие пути завершатся в первую очередь. Путем измерения конкретного набора результатов состояния гонки для каждой изготовленной схемы можно собрать профиль для каждой схемы и сохранить его в секрете, чтобы впоследствии проверить идентичность схемы.

Файловые системы [ править ]

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

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

Сеть [ править ]

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

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

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

Жизненно важные системы [ править ]

Недостатки программного обеспечения в жизненно важных системах могут иметь катастрофические последствия. Условия гонки были среди недостатков аппарата лучевой терапии Therac-25 , которые привели к смерти как минимум трех пациентов и травм еще нескольких. [17]

Другой примером является система управления энергопотреблением обеспечивает GE Energy и используется Огайо - FirstEnergy Corp (среди других энергетических объектов). Состояние гонки существовало в подсистеме сигнализации; при одновременном отключении трех провисших линий электропередач это состояние препятствовало передаче предупреждений специалистам по мониторингу, что задерживало их осознание проблемы. Этот недостаток программного обеспечения в конечном итоге привел к отключению электроэнергии в Северной Америке в 2003 году . [18] GE Energy позже разработала программный патч для исправления ранее не обнаруженной ошибки.

Инструменты [ править ]

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

Анализ безопасности потоков - это инструмент статического анализа для внутрипроцедурного статического анализа на основе аннотаций, первоначально реализованный как ветвь gcc, а теперь переопределенный в Clang с поддержкой PThreads. [19] [необходим неосновной источник ]

Инструменты динамического анализа включают:

  • Intel Inspector , средство проверки и отладки памяти и потоков для повышения надежности, безопасности и точности приложений C / C ++ и Fortran; Intel Advisor , основанный на выборке инструмент для оптимизации векторизации SIMD и поддержки потоков с общей памятью для разработчиков и архитекторов программного обеспечения на языках C, C ++, C # и Fortran;
  • ThreadSanitizer, который использует двоичный (на основе Valgrind ) или исходный код, инструментарий на основе LLVM и поддерживает PThreads); [20] [ требуется неосновной источник ] и Helgrind, инструмент Valgrind для обнаружения ошибок синхронизации в программах на C, C ++ и Fortran, которые используют примитивы потоковой передачи pthreads POSIX. [21] [необходим неосновной источник ]
  • Детектор гонки данных [22] предназначен для поиска гонок данных на языке программирования Go.

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

  • DataRaceBench [23] - это набор тестов, предназначенный для систематической и количественной оценки инструментов обнаружения гонки данных, которые анализируют многопоточные приложения, написанные на OpenMP .

В других областях [ править ]

Нейробиология демонстрирует, что расовые состояния могут возникать и в мозге млекопитающих (крыс). [24] [25]

См. Также [ править ]

  • Коллизия звонков
  • Контроль параллелизма
  • Тупик
  • Опасность (логика)
  • Линеаризуемость
  • Проблема с ипподромом
  • Синхронизация (информатика)
  • Время проверки до времени использования
  • Тест и установка

Ссылки [ править ]

  1. ^ Хаффман, Дэвид А. "Синтез схем последовательного переключения". (1954).
  2. ^ Унгер, SH (июнь 1995 г.). «Опасности, критические расы и метастабильность». Транзакции IEEE на компьютерах . 44 (6): 754–768. DOI : 10.1109 / 12.391185 .
  3. ^ «ISO / IEC 9899: 2011 - Информационные технологии - Языки программирования - C» . Iso.org . Проверено 30 января 2018 .
  4. ^ «ISO / IEC 14882: 2011» . ISO. 2 сентября 2011 . Проверено 3 сентября 2011 года .
  5. ^ Регер, Джон (2011-03-13). «Состояние гонки против гонки данных» . Встроено в Academia .
  6. ^ "Рабочий проект стандарта языка программирования C ++" (PDF) . 2014-11-19.
  7. ^ Полиграфи, Сарита & Hill, Марк & Miller, Barton & HB Нецер, Роберт. (1991). Обнаружение гонок данных в слабых системах памяти . Новости компьютерной архитектуры ACM SIGARCH. 19. 234-243. 10.1109 / ISCA.1991.1021616.
  8. ^ a b c «Глава 17. Нити и замки» . docs.oracle.com .
  9. ^ a b Adve, Sarita V .; Бём, Ханс-Дж. (2010). «Семантика совместно используемых переменных и синхронизации (также известные как модели памяти)» (PDF) .
  10. ^ Полиграфи, Сарита. (1994). Разработка моделей согласованности памяти для мультипроцессоров с общей памятью.
  11. ^ Курош Гарачорлоо и Сарита В. Адве и Ануп Гупта и Джон Л. Хеннесси и Марк Д. Хилл, Программирование для различных моделей согласованности памяти , ЖУРНАЛ ПАРАЛЛЕЛЬНЫХ И РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ, 1992, том 15, стр. 399-407
  12. ^ Синклер, Мэтью Дэвид (2017). «Глава 3: Эффективная поддержка и оценка расслабленной атомики» (PDF) . Эффективная согласованность и согласованность для специализированных иерархий памяти (PhD). Университет Иллинойса в Урбана-Шампейн.
  13. ^ «CVE-2015-8461: состояние гонки при обработке ошибок сокета может привести к ошибке утверждения в resolver.c» . Консорциум Интернет-систем . Дата обращения 5 июня 2017 .
  14. ^ a b «Уязвимость в rmtree () и remove_tree (): CVE-2017-6512» . CPAN . Дата обращения 5 июня 2017 .
  15. ^ "безопасность: кеш статистики * очень большой * состояние гонки при кешировании, когда follow_symlink отключено" . lighttpd . Дата обращения 5 июня 2017 .
  16. ^ Колеса, Адриан; Тудоран, Раду; Банеску, Себастьян (2008). «Программная генерация случайных чисел на основе условий гонки». 2008 10-й Международный симпозиум по символьным и числовым алгоритмам для научных вычислений : 439–444. DOI : 10,1109 / synasc.2008.36 . ISBN 978-0-7695-3523-4. S2CID  1586029 .
  17. ^ Левесон, Нэнси; Тернер, Кларк С. "Расследование аварий Therac-25 - I" . Courses.cs.vt.edu. Архивировано из оригинала на 2017-12-15.
  18. ^ Поулсен, Кевин (2004-04-07). «Отслеживание ошибки затемнения» . SecurityFocus . Проверено 19 сентября 2011 .
  19. ^ «Анализ безопасности потоков - документация Clang 10» . clang.llvm.org .
  20. ^ «ThreadSanitizer - документация Clang 10» . clang.llvm.org .
  21. ^ "Helgrind: детектор ошибок потока" . Valgrind .
  22. ^ "Детектор гонки данных" . Голанг .
  23. ^ "Набор тестов для гонок данных" . 25 июля 2019 г. - через GitHub.
  24. ^ «Как мозг гонится, чтобы отменить ошибочные движения» . Нейроскептик . Откройте для себя журнал. 2013-08-03.
  25. ^ Шмидт, Роберт; Левенталь, Дэниел К; Маллет, Николас; Чен, Фуцзюнь; Берке, Джошуа Д. (2013). «Отмена действий предполагает гонку между проводящими путями базальных ганглиев» . Природа Неврологии . 16 (8): 1118–24. DOI : 10.1038 / nn.3456 . PMC 3733500 . PMID 23852117 .  

Внешние ссылки [ править ]

  • Карам, GM; Бур, RJA (август 1990 г.). "Анализаторы голодания и критических рас для Ады". IEEE Transactions по разработке программного обеспечения . 16 (8): 829–843. DOI : 10.1109 / 32.57622 .
  • Фюрер, РМ; Lin, B .; Новик, С.М. (март 1995 г.). «Алгоритмы задания оптимального состояния асинхронных конечных автоматов». Перспективные исследования в СБИС, 1995. Труды., 16-я конференция о . С. 59–75. DOI : 10,1109 / ARVLSI.1995.515611 . ISBN 978-0-8186-7047-3. S2CID  4435912 . как PDF
  • Статья Лучано Лаваньо , Чо В. Муна , Роберта К. Брайтона и Альберто Санжиованни-Винчентелли « Новая структура для решения проблемы назначения состояний для спецификаций на основе событий »
  • Уилер, Дэвид А. (7 октября 2004 г.). «Безопасный программист: предотвращение состояний гонки - против вас может быть использована конкуренция за ресурсы» . IBM developerWorks . Архивировано из оригинального (PDF) 1 февраля 2009 года. Альтернативный URL
  • Глава « Избегайте условий гонки » (Безопасное программирование для Linux и Unix HOWTO)
  • Условия соревнования, безопасность и неизменность в Java , с образцом исходного кода и сравнением с кодом C, от Chiral Software
  • Карпов, Андрей (11 апреля 2009 г.). «Интервью с Дмитрием Вьюковым - автором Relacy Race Detector (RRD)» . Статьи из библиотеки программного обеспечения Intel .
  • Описание службы поддержки Microsoft
  • Состояние гонки против гонки данных