Это правильно. Процессор x86_64, как и оригинальный процессор x86, не может читать или записывать что-либо меньшее, чем (в данном случае 64-битное) слово из rsp. в память. И он обычно не читает и не записывает меньше, чем целая строка кэша, хотя существуют способы обхода кэша, особенно при записи (см. Ниже).
В этом контексте , однако, Страуструп ссылается на потенциальные гонки данных (отсутствие атомарности на наблюдаемом уровне). Эта проблема правильности не имеет отношения к x86_64 из-за протокола когерентности кэша, о котором вы упомянули. Другими словами, да, процессор ограничен передачей целых слов, , но это прозрачно обрабатывается, и вам, как программисту, вообще не нужно беспокоиться об этом. Фактически, язык C ++, начиная с C ++ 11, гарантирует , что параллельные операции в разных местах памяти имеют четко определенное поведение, то есть то, которое вы ожидаете. Даже если бы аппаратное обеспечение не гарантировало этого, реализация должна была бы найти способ, генерируя, возможно, более сложный код.
Тем не менее, все еще может быть хорошей идеей сохранить тот факт, что целые слова или даже строки кэша всегда находятся на уровне машины в задней части вашей головы, по двум причинам.
volatile
жизненно важно для предотвращения такой неподходящей оптимизации. Вот - несколько надуманный пример очень плохой структуры данных. Предположим, у вас есть 16 потоков, разбирающих текст из файла. Каждый поток имеет id
от 0 до 15.
// shared state
char c[16];
FILE *file[16];
void threadFunc(int id)
{
while ((c[id] = getc(file[id])) != EOF)
{
// ...
}
}
Это безопасно, потому что каждый поток работает в разных местах памяти. Однако эти области памяти обычно находятся на одной и той же строке кэша или, самое большее, разделяются на две строки кэша. Протокол когерентности кэша затем используется для правильной синхронизации доступа к c[id]
. И в этом заключается проблема, потому что это заставляет каждый другой поток ждать, пока строка кэша не станет исключительно доступной, прежде чем делать что-либо с c[id]
, если только он не работает на ядре, которое «владеет» строкой кэша , Предполагая несколько, например, 16, ядра, когерентность кэша, как правило, будут постоянно переносить строку кэша от одного ядра к другому. По понятным причинам этот эффект известен как «пинг-понг кеша». Это создает ужасное узкое место в производительности. Это результат очень плохого случая ложного совместного использования , то есть потоков, совместно использующих физическую строку кэша без фактического доступа к тем же логическим ячейкам памяти.
В отличие от этого, особенно если предпринять дополнительный шаг, чтобы убедиться, что массив file
находится в собственной строке кэша, его использование будет совершенно безвредным (на x86_64) с точки зрения производительности, поскольку указатели считываются только от, в большинстве случаев. В этом случае несколько ядер могут «совместно использовать» строку кэша только для чтения. Только когда любое ядро пытается выполнить запись в строку кэша, оно должно сообщить другим ядрам, что оно собирается «захватить» строку кэша для монопольного доступа.
(Это значительно упрощается, поскольку существуют разные уровни кэшей ЦП, и несколько ядер могут использовать один и тот же кэш L2 или L3, но это должно дать вам общее представление о проблеме.)
Эти ложные срабатывания тоже случаются с другими компиляторами?
Да, это была обычная проблема в прошлом для AutoIt , как описано в этом сообщении на форуме «Действительно ли мои EXE-файлы AutoIt заражены?» . В большинстве случаев, включая AutoIt , это происходит из-за плохой эвристической практики. Поскольку AutoIt использует бесплатный и открытый компрессор UPX , его часто принимают за вредоносный код, который также использует UPX .
Лучший (и, возможно, единственный) вы можете сообщить об этих ошибках, чтобы они могли уточнить свою эвристику или, по крайней мере, внести ваше приложение в белый список.
Ниже приводится список контактной информации некоторых популярных антивирусных компаний. Все они утверждают, что ценят материалы, поскольку они помогают им делать их продукт лучше. s Nod32 - Контакт
Оказывается, в википедии есть большой список антивирусного программного обеспечения, который называется «Список антивирусного программного обеспечения» . Это более полный, чем мой список выше.
Я видел, как люди, одержимые проверкой правильности, делали гораздо худшие / странные вещи, чем использование простого настраиваемого атрибута:
<base href="http://example.com/" /><!--[if IE]></base><![endif]-->
На мой взгляд, настраиваемые атрибуты действительно не имеют значения. Как говорят другие, было бы неплохо следить за будущим добавлением атрибутов в стандарты. Но теперь у нас есть атрибуты data- * в HTML5, так что мы спасены.
Что действительно важно, так это то, что у вас есть правильно вложенные теги и правильно заключенные значения атрибутов.
Я даже использую собственные имена тегов (введенные HTML5, например, header, footer и т. Д.), Но у них есть проблемы в IE.
Кстати, я часто по иронии судьбы обнаруживаю, как все эти фанатики валидации преклоняются перед умными уловками Google, такими как загрузка iframe.
Если вам это неудобно, вам, вероятно, следует сделать так, чтобы ваше антивирусное программное обеспечение предлагало вам перед тем, как предпринимать какие-либо действия, чтобы вы могли пропустить ваш файл вручную.В целом, я нашел кодирование в Windows с помощью антивирусного программного обеспечения несколько раздражающим ( в наши дни этим не занимаются, но все же), особенно если указанное программное обеспечение находится в "параноидальном режиме". Хотя это и раздражает, но неизбежно (ИМО).
Пару лет назад каждый раз, когда мы обновляли GNU Linker из исходников mingw и начинали распространять его вместе с нашим компилятором, мы получали сообщения о том, что антивирусные сканеры классифицировали ld.exe как вирус. (.exes пишет .exes ...)
В некоторых приложениях, если я использую RtlVclOptimize.pas, антивирус Avira сообщает, что я создал вирус.
Некоторый антивирус программы даже помечают командный файл как вирус и не могут убедиться, что это не так. Довольно обидно, если этот файл является частью сторонней библиотеки и предупреждение о вирусе срабатывает каждый раз, когда TortoiseSVN проверяет его. В итоге я отключил антивирусный сканер, удалил файл и сделал фиксацию. (Не отключая сканер,
плюс к тому, что говорили другие, современные антивирусные программы выдают предупреждение о вирусах, если ваши программы тоже используют некоторые «подозрительные» API (например, URLdownloadFile или другие API, связанные с перехватом). если вы погуглите "delphi RAT FUD API undetectable", вы найдете много интересных тем.
Это случилось со мной с развернутым кодом. Следующее обновление сканера решило проблему. Какой-то кретин написал вирус, используя тот же компилятор, и подпись была частью библиотеки времени выполнения, а не во враждебном коде.
Yes, my team has experienced this maybe half a dozen times in 2-3 years with Sophos in a corporate environment. So, very rarely, but it does happen.
Our IT cretin started off demanding I review all the 1.5M lines of code in our app to "make it go away", but he didn't get too far pursuing that line...
To be fair, he was initially concerned that our clients might also receive such a warning, but we've only ever seen it triggered when building an exe from the IDE on a developer's PC, never on a release build exe on a test box or elsewhere.
Personally, it happens so rarely we don't worry about it.
Это случилось и со мной. Подключаемая клавиатура запускает почти любое эвристическое сканирование антивирусной программы, чтобы сообщить о ключевом регистраторе. Вероятно, есть много других системных вызовов, которые также вызовут его. Решение - попробуйте изменить код или обратитесь к производителю AV, чтобы включить ваше программное обеспечение в список исключений.
Я видел это только с ассемблерами. Например, MASM32 на самом деле предупреждает людей, что он может запускать антивирусные сканеры, поскольку EXE-файлы очень малы (и / или некоторые вирусы написаны на ассемблере). Мой сканер McAfee пометил некоторые из примеров программ как вирусы.
Это должно происходить только с антивирусными сканерами, которые имеют режим анализа «выглядит подозрительно».
Я никогда не видел этого, поскольку много раз работал над C ++ и .NET с помощью Visual Studio (с версии 1.5 по 2010).
Это не такая уж редкость при использовании нестандартных компиляторов или при выполнении фантастических низкоуровневых вещей: я помню, как создавал ложные срабатывания, когда баловался разработкой ОС: AntiVir не нравились некоторые из мои плоские двоичные файлы.
Недавно в списке рассылки tinyCC , посвященном AVG, появилось сообщение о такой проблеме.
Для меня это больше похоже на эвристический провал. Включена ли эвристика (некоторые сканеры могут называть ее "вирусоподобным кодом")? Вероятность того, что метки времени будут соответствовать «части какой-то вирусной сигнатуры», кажется слишком малой, чтобы происходить постоянно.
Когда я использовал антивирусный сканер, я никогда не видел этой проблемы с D6 или D7.
Я помню еще одну странность:
Файл был помечен как подозрительный. Единственное, это файл в формате .OBJ! .EXE, содержащий код, содержащийся в .OBJ, не считался проблемой.
В дикой природе действительно есть вирус Delphi, см. http://www.sophos.com/blogs/sophoslabs/?p=6117
Если у вас есть проблемы с ложными срабатываниями, существует онлайн-сервис VirusTotal , который может помочь вам проверить ваш файл на соответствие нескольким антивирусным ядрам.
Это бесплатный сервис, и в настоящее время он может запускать антивирусную проверку почти с 40 антивирусными ядрами.