Где-то видел такую фразу на форуме: "Страшно, когда разработчики драйверов рассуждают о вероятности падения системы". И все же новичкам простительно Меня интересует вопрос спасёт ли try - except например на 2-х ядерной машине при одновременном чтении-записи в глобальной переменной из разных потоков? В драйвере используется глобальная переменнная типа BOOLEAN. Она довольно часто проверяется в других потоках, но меняет своё значение только 1 раз в другом потоке. Спрашивается имеет ли смысл читать и писать в эту переменную в блоках SEH. Или всё же делать критическую секцию?
Не совсем понятно от чего try - except будет спасать . Он используеться, когда может возникнуть исключение. Но при чтении валидной области памяти (какой является своя переменная) никаких исключений не будет, даже если ее одновременно читают и изменяют несколько потоков. Для синхронизации совместно используемых данных надо использовать соответствующие синхронизационные примитивы, а не try - except . Например, в случае одной переменной типа BOOLEAN можно использовать InterlockedXXX функции.
DriversDeveloper надо же я всегда думал что бяка будет таким образом для BOOLEAN можно вообще ничего не делать это ведь не какая-то строка например, которая может неправильно интерпретироваться при одноврменном чтении-записи
А разве не возникнет никакого исключение если в одно и тоже время один поток будет писать а другой читать ячейку памяти?
Исключения то не будет, но а если "ячейка памяти" большая (многобайтовая)... то синхронизации не избежать
asmfan Да даже если однобайтовая. Все равно есть вероятность, что 2 потока обратятся к ней одновременно, на многопроцессорных машинах 1 поток считал число а другой в это же время записал. Первый поток, вернет новое или старое значение ??? Я считаю, что синхронизация нужна даже в таком случае (да хотя бы XCHG)
TermoSINteZ Вернёт то которое валидное на момент чтения. Никто ж не говорит про последующие исполняемые инструкции, а только про операции чтение/запись. если чтение/запись+модификация/сравнение то тут надо атомарность включать, а чтение/запись уже атомарны в пределах размеров регистров (насчёт xmm не уверен, если ширина шины меньше). В общем не всё так гладко и ясно. +в note'ах от интела интересно сказано, что lock может появиться внутренне сам по себе в последних процессорах. +просто лочится кэш-линия... уффф... условностей сколько. Хорошо бы чтобы кто-нить чуток прояснил вопрос (даже если и в -надцатый раз.
asmfan Да, я как раз и имел ввиду дальнейшую логику работы программы... в этом самая большая проблема синхронизации в многопоточных и многопроцессорынх средах. Представте какие будут поледствия, при реализации критических секций. В науке, помимо проблемы рассогласованности (про больших объемах данных), есть еще "проблема тупиков".