Тестирование параллельной структуры данных

Question

Каковы некоторые методы тестирования параллельных структур данных, чтобы убедиться, что структуры данных ведут себя правильно при доступе из нескольких потоков?

Answer 1

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

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

Answer 2

Используйте уже существующую, предварительно протестированную библиотеку, которая соответствует вашим потребностям, если это возможно.

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

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

Настроить группу потоков, которые делают только случайные операции со структурами данных и проверять согласованность с некоторой скоростью.

Answer 3

Обычно я проверяю подобные вещи, прерывая вызовы sleep() в соответствующих местах в распределенных потоках / процессах.

Например, чтобы проверить блокировку, поместите sleep(2) во все ваши потоки в точке разногласия и создайте два потока с интервалом примерно в 1 секунду. Первый должен получить блокировку, а второй должен ждать ее.

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

Answer 4

Все остальные ответы были направлены на то, чтобы на самом деле протестировать код, пройдя его через все шаги и фактически запустив его в той или иной форме или вежливо сказав: «Не делай это сам, используй существующую библиотеку».

Это замечательно и все, но IMO, самый важный (практические тесты тоже важны) тест, состоит в том, чтобы построчно смотреть на код, а для каждой строки кода спрашивать "что произойдет, еслибыть прерванным другим потоком здесь? "Представьте себе другой поток, выполняющий практически любые другие строки / функции во время этого прерывания.Все еще остается неизменным?Когда мы конкурируем за ресурсы, другой поток блокирует или вращает?

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

Answer 5

Параллельные системы являются вероятностными, а ошибки часто трудно воспроизвести.Поэтому вам необходимо запускать различные варианты ввода / вывода, каждый из которых проверен с течением времени (часы, дни и т. Д.), Чтобы обнаружить возможные ошибки.

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

Answer 6

Запустите ваши параллельные потоки на один или несколько дней и посмотрите, что произойдет.(Звучит странно, но выяснение условий гонки - такая сложная тема, что просто попытка сделать это - лучший способ)