Я написал программу которая вычисляет одну фигню(неважно какую). Так при определенных параметрах вычислительный процесс может быть очень долгим. Как сделать так, чтобы пользователь мог остановить процесс вычисления кнопкой на форме. Заранее спасибо

Заводишь глобальную переменную
var gStop:Boolean;
В начале вычисления делаешь ее false
gStop := False;
В цикле вычисления пишешь
Application.ProcessMessages;
if gStop then
begin
break;
end;
На событие нажатия на кнопку STOP пишешь
gStop := True;

Это сообщение отредактировал(а) Matematik - 27.3.2006, 10:04

спасибо огромное, все работает.
интересно а что делает Application.ProcessMessages;

обрабатывает полученные программой сообщения (за время работы от Application.ProcessMessages до Application.ProcessMessages или от начала процедуры до первого Application.ProcessMessages)

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

что не тред-сейф.
Добавлено @ 11:14
используй interlocked-функции

с какого перепуга?

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

это если два потока пишут а один читает ( и временами тоже пишет )
а если один читае а другой пишет да еще и один байт ( и нужен нам из него один бит ) все безопасно

Достаточно одного;)

с учетом:

?

кстати если два ( или больше ) потока пишут в один ресурс -- это тоже вполне потоково-безопасная операция

Это что, шутка такая??

почему? я же нигде не писал о чтении... ;)

Ну тогда позволь возразить.



В корне неверно.

??? почему?

_hunter, прав если предварительно значение не считывать, то будет все в порядке.

а на двух процах?

если ресур общий ( а память -- общая ) всеравно.
вот если на двух компах...

Не все равно.

Смысл всех этих потуг с синхронизацией заключается в том, чтобы данные были в согласованном состоянии.

Простая ситуация: 2 потока, обрабатыва.щие однц и ту же строку:

Последовательная обработка, когда потоки работают последовательно:

Первый поток записывает в строку: CommonStr := '1234567890';
Первый поток читает строку и обрабатывает ее; //Строка '1234567890'
Второй поток записывает в строку: CommonStr := 'abcefghij';
Второй поток читает строку и обрабатывает ее; //Строка 'abcefghij'

Параллельная обработка:

Первый поток записывает в строку: CommonStr := '1234567890';
//Первый поток успевает записать только '123'
Второй поток записывает в строку: CommonStr := 'abcefghij';
//Второй поток успевает записать всю строку
Первый поток продолжает записывать оставшуюся часть строки '4567890'
Первый поток читает строку и обрабатывает ее; //Строка 'abc4567890'
Второй поток читает строку и обрабатывает ее; //Строка 'abc4567890'

Это всего лишь схематично. На самом деле все намного сложнее.

вопрос звучал не читать, а только писать
читать может только третий

читать нужно было так:
если ресур общий всеравно будет затык.

И в результате прочитает полную чушь.

В общем, процесс синхронизации необходим всегда, за исключеним работы с типом Byte и Boolean.

а так же word, DWord, extended.

mov [....], eax

mov [....], ax

mov [....], al

одна команда


иногда может оказаться что и так сойдет(правда редко)
шучу, конечно

а вообще если record писать то и в правду нельзя

Это сообщение отредактировал(а) alexeis1 - 27.3.2006, 16:20

А так? -


С Integer и Extended еще хуже.

Это сообщение отредактировал(а) Демо - 27.3.2006, 16:33

Демо, integer, Cardinal, LongWord, DWord - для процессора - это один и тот же тип. Для записи значения из регистра в память используется одна машинная команда ( которую никто не может прервать).
ее аналог в ассемблере
mov DW1, eax (ebx, ecx...)
таким образом запись в память производится за один такт.
c Extended - работает сопроцессор
Extended - это также атомарный тип также будет обрабатываться за такт.

alexeis1,

Посмотри, какой код получается сначала.

Все типы, кроме однобайтовых, необходимо защищать.

чем хуже Будет правельно.
Добавлено @ 11:51
Демо, покажи ассемблерный код которыу получится

alexeis1,





2 команды. Или я что-то не понял?

Хм... А если просто:

Guedda,
Ну мы же не на ассемблере пишем;)

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

На большинстве компьютеров увеличение значения переменной не является атомарной операцией, а требует следующих шагов:

- Загрузить значение из переменной экземпляра в регистр.
- Увеличить или уменьшить значение.
- Сохранить значение в переменной экземпляра.

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

ВОТ что показал делфи
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


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