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


Очень рад, что у нас развернулась такая интересная и конструктивная дискуссия. Зачем она была мне нужна? Да все очень просто. Поначалу я действительно не знал, в чем проблема и перебирал в уме разные версии. Потом, начал пробовать разные тулы, например Thread Cheker с опцией /t_check и без нее, разные компиляторы, разбирать пример по ассемблерным командам... Далее проблема разрешилась, но мне стало интересно, что думают о ней другие коллеги, желательно не интеловцы (которые, кстати, постоянно вклинивались в эту ветку со своими правильными предположениями, сбивая весь кайф от общения с сообществом , тем не менее, спасибо им огромное за подсказки). Собственно я хотел увидеть стройную нить рассуждения по озвученной проблеме и хоть какие-нибудь усилия по проверке примерчика любыми другими способами.

Наиболее близко к истине подобрался Дмитрий Вьюков, который высказал мысль о том, что цель нахождения абсолютно всех ошибок конфронтирует с требованием более-менее быстрой работы. Да что там близко, прямо в точку попал! Практически вплотную Дмитрий подобрался к разрешению этой проблемы с Инспектором: «Возможно там есть какие-то настройки касательно "уровня дотошности и тормознутости" проверки». Как указала Юлия в крайнем сообщении, необходимо было прогнать примерчик на уровне ti4 (самый высокий уровень «дотошности»), и в результате получить полную диагностику ошибки. Я слегка удивлен, что так никто этого и не попробовал сделать.

Ну а вот «официальная» версия происходящего. Не раскрывая особых секретов внутренней имплементации Инспектора (они не известны даже мне), можно сказать, что инструмент отслеживает доступ к памяти потоками, выделяя подобные участки в «теневой» памяти и сохраняя историю доступа потоков к ним и вызовов функций синхронизации. Однако копировать все данные в «теневую» память было бы чрезвычайно накладно, поэтому инструмент поступает следующим образом. Если поток Т1 один раз обращается к памяти 0хNNNN, то ничего не происходит (за исключением сохранения «истории» факта этого доступа). Далее, если поток T2 обратился к той же памяти, то это уже сигнал к тому, чтобы сохранить объект в «теневой» области и начать отслеживать дальнейшие обращения к нему. Однако, если эта память больше не читается/пишется, то никаких дальнейших действий в отношении анализа доступа не производится. Так собственно и происходило в нашем примерчике. Одна и та же переменная g_var была «тронута» каждым из двух потоков, при этом не происходило пересечения обращения к переменной и наступления событий синхронизации или активности другого потока, что вызвало создание «теневой» ячейки под g_var и не более того. Вот если бы мы установили три и более исполняемых потока, или произвели еще какую-либо операцию над g_var, то тогда бы «гонка» была диагностирована.

Сделано это исключительно для того, чтобы резко снизить накладные расходы на анализ любого обращения к памяти, которое так и останется единичным обращением. В результате мы можем получить такие вот вырожденные случаи, когда на уровнях ti2-ti3 очевидные «гонки» не обнаруживаются, хотя по заявленным описаниям должны бы. Но на то они и вырожденные случаи, чтобы встречаться в практике в реальных программах крайне редко. Разработчики считают, что данный компромис никак не отразится на качестве обнаружения потоковых проблем в реальных приложениях.

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

А звание «Титана параллелного программирования», командирскую майку (пока виртуальную), всенародную славу и почет заслуженно получает, прямо перед строем, Дмитрий Вьюков, с чем его горячо поздравляем и желаем дальнейших успехов на этом нелегком поприще.