Случайно созданный вирус?

Question

Случайно созданный вирус?

Это правильно. Процессор x86_64, как и оригинальный процессор x86, не может читать или записывать что-либо меньшее, чем (в данном случае 64-битное) слово из rsp. в память. И он обычно не читает и не записывает меньше, чем целая строка кэша, хотя существуют способы обхода кэша, особенно при записи (см. Ниже).

В этом контексте , однако, Страуструп ссылается на потенциальные гонки данных (отсутствие атомарности на наблюдаемом уровне). Эта проблема правильности не имеет отношения к x86_64 из-за протокола когерентности кэша, о котором вы упомянули. Другими словами, да, процессор ограничен передачей целых слов, , но это прозрачно обрабатывается, и вам, как программисту, вообще не нужно беспокоиться об этом. Фактически, язык C ++, начиная с C ++ 11, гарантирует , что параллельные операции в разных местах памяти имеют четко определенное поведение, то есть то, которое вы ожидаете. Даже если бы аппаратное обеспечение не гарантировало этого, реализация должна была бы найти способ, генерируя, возможно, более сложный код.

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

Во-первых, и это актуально только для людей, которые пишут драйверы устройств или разрабатывают устройства, отображаемый в памяти ввод-вывод может быть чувствительным к способу доступа к нему. В качестве примера рассмотрим устройство, которое предоставляет 64-битный регистр команд только для записи в физическом адресном пространстве. Тогда может потребоваться:
- Отключить кэширование. Недопустимо читать строку кэша, изменять одно слово и записывать обратно строку кэша. Кроме того, даже если бы он был действительным, все равно был бы большой риск того, что команды могут быть потеряны, поскольку кэш-память ЦП не достаточно быстро записывается. По крайней мере, страница должна быть настроена как сквозная, что означает, что запись вступает в силу немедленно. Поэтому запись таблицы страниц x86_64 содержит флаги, которые управляют поведением кэширования ЦП для этой страницы .
- Убедитесь, что все слово всегда написано на уровне сборки. Например. рассмотрим случай, когда вы записываете значение 1 в регистр, за которым следует 2. Компилятор, особенно при оптимизации пространства, может решить перезаписать только младший байт, поскольку остальные уже должны быть равны нулю (то есть для обычной оперативной памяти), или он может вместо этого удалить первую запись, потому что это значение, по-видимому, немедленно перезаписывается. Однако здесь не должно происходить ни того, ни другого. В C / C ++ ключевое слово 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, но это должно дать вам общее представление о проблеме.)

55

virus delphi antivirus false-positive

задан Wim ten Brink 27 July 2010 в 10:26

16 ответов

Я видел, как люди, одержимые проверкой правильности, делали гораздо худшие / странные вещи, чем использование простого настраиваемого атрибута:

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

На мой взгляд, настраиваемые атрибуты действительно не имеют значения. Как говорят другие, было бы неплохо следить за будущим добавлением атрибутов в стандарты. Но теперь у нас есть атрибуты data- * в HTML5, так что мы спасены.

Что действительно важно, так это то, что у вас есть правильно вложенные теги и правильно заключенные значения атрибутов.

Я даже использую собственные имена тегов (введенные HTML5, например, header, footer и т. Д.), Но у них есть проблемы в IE.

Кстати, я часто по иронии судьбы обнаруживаю, как все эти фанатики валидации преклоняются перед умными уловками Google, такими как загрузка iframe.

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

В целом, я нашел кодирование в Windows с помощью антивирусного программного обеспечения несколько раздражающим ( в наши дни этим не занимаются, но все же), особенно если указанное программное обеспечение находится в "параноидальном режиме". Хотя это и раздражает, но неизбежно (ИМО).

1