Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Мирное сосуществование PC-Lint и VivaMP

Мирное сосуществование PC-Lint и VivaMP

23 Фев 2009

Нам задают различные вопросы, связанные с использованием PC-Lint, VivaMP и других статических анализаторов для проверки параллельных программ, спрашивают, являются ли они конкурентами и задают другие схожие вопросы. Видимо это связанно с выходом новой версии PC-Lint 9.0, в которой заявлено о поддержке анализа параллельности (см. PC-lint Manual. Раздел: 12. Multi-thread support). Я решил объединить обсуждения, в которых я участвовал по этому поводу и представить их в виде двух вопросов, на которые я дам развернутые ответы.

Поддержка VivaMP была прекращена в 2014 году. По всем возникшим вопросам вы можете обратиться в нашу поддержку.

Вопрос первый.

Можно ли использовать PC-Lint для проверки параллельных программ?

Этот вопрос часто задают, но, к сожалению, он не удачен. Прямой на него ответ - да. Но люди на самом деле вкладывают в этот вопрос другой смысл - "Можно ли используя PC-Lint найти ошибки в программах, связанных с использованием распараллеливания алгоритмов?". Тогда ответ - нет, если не предпринять специальных действий.

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

1) Статические анализаторы, как и компиляторы, работают с каждым .cpp файлом отдельно. И поэтому, если в файле A параллельно вызывается функция f() из файла B, то при анализе файла B мы не знаем об этом. Конечно, можно создать статические анализаторы (возможно, такие и есть), которые анализируют все файлы сразу, но это крайне сложная задача. По крайней мере, PC-Lint работает с каждым файлом отдельно.

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

Возьмем пример функции (приведенный в руководстве к PC-Lint версии 9.0):

void f()
{
  static int n = 0;
  /* ... */
}

Проблема состоит в том, что если функция f() будет вызвана из параллельных потоков, то может возникнуть ошибка инициализации переменной 'n'. Для диагностики данной ситуации, необходимо явно указать анализатору PC-Lint, что функция f() может вызываться параллельно. Для этого необходимо использовать конструкции вида:

//lint -sem(f, thread)

Только тогда, при диагностике кода, вы получите предупреждение: Warning 457: "Thread 'f(void)' has an unprotected write access to variable 'n' which is used by thread 'f(void)" .

На самом деле, высказанное мною ранее утверждение, что, не предпринимая специальных действий, нельзя автоматически диагностировать ошибки в параллельном коде не совсем верно. PC-Lint поддерживает POSIX threads и может, например, автоматически обнаружить ошибки связанные с блокировками, если будут использоваться такие функции, как pthread_mutex_lock() и pthread_mutex_unlock(). Но если механизм параллельности построен не на POSIX threads, то вам опять-таки будет необходимо использовать специальные директивы, чтобы подсказать PC-Lint какие функции приводят к блокировке и разблокировке:

-sem(function-name, thread_lock)

-sem(function-name, thread_unlock)

В этом случае можно обнаружить ошибки в коде, подобному следующему:

//lint -sem( lock, thread_lock )
//lint -sem( unlock, thread_unlock )
extern int g();
void lock(void), unlock(void);
void f()
{
  //-------------
  lock();
  if( g() )
    return; // Warning 454
  unlock();
  //-------------
  if( g() )
  {
    lock();
    unlock();
    unlock(); // Warning 455
    return;
  }
  //-------------
  if( g() )
    lock();
  { // Warning 456
    // do something interesting
  }
}

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

Из всего описанного вытекает второй вопрос.

Если анализатор PC-Lint позволяет искать ошибки связанные с параллельностью, то имеет ли смысл использовать VivaMP?

Ответа два:

1) PC-Lint не умеет находить ошибки в программах, построенных на технологии OpenMP.

2) VivaMP специализированный продукт для диагностики параллельных программ, в то время как PC-Lint хороший статический анализатор общего назначения. Еще раз подчеркну: хороший, но общего назначения. Анализ параллельности в нем это всего лишь одна из подсистем. Инструмент VivaMP специально создан для диагностики параллельных программ и обладает большими возможностями в этой области.

Можно заявить, что VivaMP и PC-Lint не являются конкурентами. Они дополняют друг друга. То, что умеет диагностировать VivaMP не умеет делать PC-Lint. То, что умеет делать PC-Lint, не умеет VivaMP. Но постепенно учится :). Поясню это на примерах.

Вновь возьмем пример со статической переменной:

void f()
{
  #pragma omp parallel num_threads(2)
  {
    static int cachedResult = ComputeSomethingSlowly();
    ...
  }
  ...
}

Статическая переменная объявлена внутри параллельной OpenMP секции, что приведет к ошибке инициализации. В данном примере PC-Lint не способен обнаружить ошибку. Мы не можем указать, что функция f() выполняется параллельно, поскольку в данном примере только часть кода функции будет распараллелена. VivaMP же обнаружит ошибку и выдаст сообщение: V1204. Data race risk. Unprotected static variable declaration in a parallel code.

Аналогичная ситуация будет в случае ошибки с блокировкой/разблокировкой. Рассмотрим следующий код:

void foo()
{
  ...
  #pragma omp parallel sections
  {
    #pragma omp section // V1102.
    {
      omp_set_lock(&myLock);
    }
    #pragma omp section // V1102.
    {
      omp_unset_lock(&myLock);
    }
  }
  ...
}

В данном случае есть две OpenMP директивы, которые в двух секциях несимметрично используют функции omp_set_lock и omp_unset_lock. То есть приведенный код содержит две ошибки, о которых и сообщит анализатор VivaMP (V1102. Non-symmetrical use of set/unset functions for the following lock variable(s): myLock).

А вот PC-Lint здесь помочь не сможет. Дело в том, что OpenMP директивы для него ничего не значат, то есть он просто их игнорирует. А следовательно с точки зрения PC-Lint код будет выглядеть так:

//lint -sem(omp_set_lock, thread_lock)
//lint -sem(omp_unset_lock, thread_unlock)
void foo()
{
  ...
  {
    omp_set_lock(&myLock);
  }
  {
    omp_unset_lock(&myLock);
  }
  ...
}

Даже если мы укажем для PC-Lint, что omp_set_lock/omp_unset_lock используется для блокировки/разблокировки, то для него функция foo() в отличие от VivaMP будет корректна. Есть одна блокировка и одна разблокировка. Ошибки нет.

Еще раз повторю, что причина в том, что PC-Lint не анализирует директивы OpenMP заданные с помощью конструкций #pragma, из-за чего логика алгоритма для него представляется по-иному.

Вывод

VivaMP и PC-Lint два хороших инструмента, ориентированных на различные аспекты параллельного программирования, и отлично дополняют друг друга.

Популярные статьи по теме
PVS-Studio для Java

Дата: 17 Янв 2019

Автор: Андрей Карпов

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

Автор: Андрей Карпов

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

Автор: Андрей Карпов

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

Автор: Андрей Карпов

Краткое описание технологий, используемых в инструменте PVS-Studio, которые позволяют эффективно обнаруживать большое количество паттернов ошибок и потенциальных уязвимостей. Статья описывает реализа…
PVS-Studio ROI

Дата: 30 Янв 2019

Автор: Андрей Карпов

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

Дата: 22 Окт 2018

Автор: Андрей Карпов

PVS-Studio, как и другие статические анализаторы кода, часто выдаёт ложные срабатывания. Но не стоит спешить считать странные срабатывания ложными. Это короткая история о том, как PVS-Studio вновь ок…
Любите статический анализ кода!

Дата: 16 Окт 2017

Автор: Андрей Карпов

Я в шоке от возможностей статического анализа кода, хотя сам участвую в разработке инструмента PVS-Studio. На днях я был искренне удивлён тому, что анализатор оказался умнее и внимательнее меня.
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

Автор: Андрей Карпов

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

Автор: Андрей Карпов

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14 Апр 2016

Автор: Андрей Карпов

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…

Комментарии (0)

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