Инструмент для обнаружения гонки данных?

https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual

https://software.intel.com/ru-ru/inspector

Но может есть какая то хитрая утилита которая сразу ткнет меня носом - вот тут конфликт между потоками?

Тебе в рантайме или статически?

Это решается через формальные методы, например вот https://dev.by/news/marsokod-ili-kak-sozdavalos-po-dlya-marsohoda-curiosity

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

Но формальная верификация это сложно и дорого. А так я могу посоветовать прогнать через https://valgrind.org/docs/manual/drd-manual.html и воспользоваться статическими анализаторами. Про санитайзеры тут уже выше упоминали

Кстати, упомянутый в цитате Spin является опенсорсным, его можно скачать и попробовать им что-то доказать. Только он не для плюсов, он для Си. https://spinroot.com/spin/whatispin.html

Переписать на расте

В рантайме.

А теперь как мне проверить что это правильно работает?;-)

Самый лучший способ - это доказать (как доказывают теоремы в математике). Ни один из runtime checker-ов (valgrind, sanitizers) не могут доказать отсутствие ошибок, они лишь могут указать на проблемы, которые воспроизведутся в конкретном случае.

Иными словами, стоит написать так, чтобы было очевидно отсутствие ошибок. Стоит быть крайне осторожным с

я хитро извернулся

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

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

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

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

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

В openMP есть блокировки omp_lock_t которая тот же мьютекс

Я в курсе, что есть set_lock и unset_lock, но суть в том, что может все таки воспользоваться task, например, (я не знаю, что за задача и как ее реализовывали, может еще какие-то конструкции из openmp взять), прежде чем бросаться и вручную реализовывать синхронизацию доступа к данным. Почему бы эту задачу не отдать на откуп OpenMP, собственно и для этого тоже он и задумывался.

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

Если речь про кластер, то насколько я знаю - никак. Только сети Петри и вот это вот все. Но, можно схитрить и охладить все в одном бинарнике, тогда, по идее может и hellgrind сработать.

Речь идёт о запуске на одном узле кластера, но там 56 потоков. Но меня устроит и тест на ноуте в 4 потока

А может все таки проще не давать советов по задаче которой ты не знаешь и о которых Вас не просили?:-)

Может проще все таки ознакомиться с технологией программирования, прежде чем приступать к задаче. См. например. Intel Thread Checker (или Intel Inspector). Может быть здесь еще что-то окажется полезным. https://en.wikipedia.org/wiki/Race_condition#Tools

ThreadSanitizer просто прекрасно ловит такие проблемы, будь то pthreads или что-то что использует это под капотом

У ThreadSanitizer есть ограничения. Далеко не все типы блокировок оно поддерживает, нужно читать доки. Если OpenMP использует что-то неподдерживаемое то пролетели, а если pthread mutex то тогда годится

Спасибо.

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

Корректность многопоточного софта практически невозможно доказать численными методами. Ибо космическое число вариантов исполнения. А вот аналитически уже реально. Рекомендую следовать советам [url=«https://www.linux.org.ru/forum/development/15446804?cid=15447993»]kawaii_neko[/url]

(разметку сломали?)