Синхронизация одного потока

[waleri]

CRITICAL_SECTION реентрантна, поэтому вызов EnterCriticalSection дважды из одного потока синхронизации не дает. Вы входите в секцию при первом нажатии кнопки, потом, пока ждете завершения потока, прокручиваете сообщения и получаете второе нажатие, в том же UI потоке, что и первое нажатие и входите в секцию второй раз, создаете второй поток и тд. Получаетеся, что UI инициализирует ваши данные второй раз, во время работы первого потока.

[zumm]

waleri, да, я знаю. Именно поэтому я и попытался использовать синхронизацию потока с помощью флага. Но почему происходит зависание?

откуда ты это выражение взял то?

Это из личных представлений о работе окон.)

[the_deer_one]

Может флажок volatile ом сделать ?

[zumm]

Может флажок volatile ом сделать ?

Поподробнее.

[the_deer_one]

Ну специальная фигня такаяб что бы ничего хитро не закешировалось.
http://en.wikipedia.org/wiki/Volatile_variable

[zumm]

the_deer_one, не вижу в этом смысла. Флаг не подвергается оптимизации компилятора.

[waleri]

Сообщение от zumm

Но почему происходит зависание?

Потому что обнуление флага делается в UI потоке, который при повторном нажатии случае зашел в while(flag) { } и никогда от туда не вышел.

[zumm]

waleri, такс... Не могли бы вы мне объяснить логику работы? При повторном нажатии на кнопку, куда идет UI поток? Он тормозит обработку первого вызова и переходит ко второму? Так? После обработки второго вывоза он возвращается к обработке первого вызова?

[evg_m]

передлагаю рассмотреть такую схему работы

1. UI поток. с помощью кр. секции (или без нее) готовим данные. затем стартуем поток(пока БЕЗ блокировки). (с передачей! данных)
2. MY поток. СРАЗУ при старте! блокируем "свои" данные с помощью кр. секции. и считаем
3. UI периодически (таймер!!!) проверяем готовность расчета(блокировку данных).
4. MY поток заканчивает расчет и разблокирует "освобождаем" данные.
5. UI поток проверяем блокировку. принимаем и чистим. (на самом деле это другая ветвь п.3 ) если занято то выход иначе очистить

Нет пляски с "петлей" (вся пляска "прячется" в таймер") .
Нет никаких флагов, точнее таковым выступает сама критическая секция (для чего собственно она и предназначена)!

А если потоку добавить функциональность по извещению UI о конце расчетов (CallBack функцию / PostMessage(WM_USER+... ) ), то и таймер становится не нужным.

Offtop: О да при этом мы "перешли" от функциональной модели работы к "почти" событийной.

СРАЗУ при старте

означает сразу при входе в потоковую функцию!!! ThreadProcedure!

поток заканчивает расчет и разблокирует "освобождаем" данные.

В конце потоковой функции!! ThreadProcedure!

procedure ThreadPRocedure;
{
  EnterCriticalSection(LockSection); //сразу при старте
....// здесь что-то считаем
  LeaveCriticalSection(LockSection); // в конце расчета или ПРИ СБОЕ ! ( try ... finally )
}

[the_deer_one]

а вариант с флагом и лупом почему не работал, на вид он стрёмный, но работать то должен хотя бы в большинстве случаев.