ВОТ что показал делфи
http://alexei-s1.narod.ru/prog.jpg
как я и предпологал одна команда
mov [epb-$08], eax
и
mov [ebp-$0C], $000000004
Добавлено @ 13:08
Переключение процессов не приводит к потере значений регистров
так что все будет как надо

Ну в предыдущем постинге ведь было написано, ЧТО будет потеряно. А именно - значение, присвоенное переменной во втором потоке. Если выполнение программы зависит от этого значения - вот и труднонаходимая (практически невозможно отловить) ошибка.

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

В приведенном примере НЕ БУДЕТ равен значению из второго потока, и этим значение не удастся воспользоваться. оно просто будет потеряно. Для того, чтобы этого не происходило, и существуют такие функции как InterLocked*

Как же не будет?? когда команда мов его туда запишет(кто помешает записать???????)

Для того же примера, который приводил -
простая операция присваивания

не будет выполнена при условиях из Демо (Дата 29.3.2006, 12:44)
Добавлено @ 13:48
Здесь DW1 и D - глобальные

DW1 := D;

Первый поток: mov eax,[D]
<Переключение контекста>
Второй поток: mov eax,[D]
Второй поток: mov [DW1],eax
<Переключение контекста>
Первый поток: mov [DW1],eax

Демо, ничего себе, оба потока при этом для чтения используют другую глобальную переменную D - такого оговорено не было.
Общая ячейка только одна и каждый может писать в нее все что хочет в любое время и результат будет зависить от того кто последним записал. Ни один из двух потоков не имеет право на считывание значения из этой ячейки.

Это сообщение отредактировал(а) alexeis1 - 29.3.2006, 14:02

А что - это ситуация нестандартная?



Не надо налагать какие-то дополнительные ограничения. Факт один - эта операция не SafeThread.

А Вы на флаги, люди смотрите?
Когда один поток начинает работать с глобальной переменной, то флаг поднимается, и другой тред не может получить доступа к этой же глобальной переменной. И начинает ждать... Посмотрите внимательней в окно CPU

Факт состоит в том, что
1) чтение с записью из общей памяти (не важно из какой части общей памяти) - потоконебезопасно
2) запись без чтения из общей памяти - потокобезопастно

И что из этого следует? Только то, что запись без чтения никому не нужна.
Добавлено @ 14:24
Действительно - зачем писать куда-то, если не предполагается читать оттуда?
Добавлено @ 14:24
Проще тогда не писать. И защищать код тогда не придется.

не предполагается читать оттуда потоками 1 и 2.
Поток же 3 - который ни чего не пишет в общую память - спокойно оттуда читает.

На самом деле иногда применяют схемы доступа к общей памяти с неполным взаимоисключением - например: Один пишет - все ждут, никто не пишет - все читают.
Случай который мы рассматриваем так же из разряда не полного взаимоисключения. Например задача пребразования элементов массива. Несколько потоков читают данные из одного массива и пишут в другой - каждый считает только часть массива (фрагмент или в случайном порядке) - может оказаться что диапазоны входных данных и выходных перекрывются, т.о. Два потока могут писать данные в общие ячейки - в этом случае нет необходимости взаимоисключения как по входным, так и по выходным данным.

Ну что хоть чуть-чуть убедил

Конечно, нет.

Нет смысла говорить о согласованности данных, когда эта согласованность не нужна.
Если в результате работы потоков достаточно получить неизвестный мусор - почему бы и нет.

Но говорить о том, что не нужна синхронизация, да еще проповедовать неверную доктрину, подходящую только для весьма ограниченного круга задач - я бы сказал(как это помягче) - некорректно.

В данном случае работа потоков как раз таки согласована(так сказать "строго регламенирована"), может быть даже синхронизированна, отсутствует только избыточное взаимоисключение.

Результат описанной задачи (с массивом) при той реализации, будет однозначным.
Я и не говорил, что это решение универсальное.


Кстати - это не я придумал, а прочитал в умной книжке.
Что-то похожее я читал даже в статье Петровича(перевод книги про многопоточность), закрепленной в разделе Delpi Api програмирование.
Область применения неполного взаимоисключения не так уж мала.
Существуют даже удаленные БД с многопользовательским доступом,
реализаванные на принципе неполного взаимоисключения.

Кстати о полном взаимоисключении - если слишком с этим перестараться, то можно сталкнуться с весьма "непонятными" ошибками связанными с возникающими тупиками, причем определить место и причину появления иногда невероятно сложно, даже для профи.
Хотелось, бы сделать небольшое заключение.
Для работы с потоками, требуется внимание, точность и большая аккуратность, а "оржие" выбирать нужно согласно размеру "зверя",для каждой задачи свое.

Подскажи, где в переводе статьи наяти что-от подобное?
Добавлено @ 12:24


Кстати, намного сложнее найти ошибку, если синхронизация не используется.