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

В случае с гридом... есть мысль... только в качестве буферной переменной юзать нечто куда будет выливаться результат запроса. Как недостаток следует признать необходимость полного fetch записей.

Alexey Kovyazin
по поводу "gds32 не поддерживает многопоточный доступ"... Странно... Во-первых, я это использую, причем тестировал в режиме когда это удовольствие обязано было свалится... Да и потом... dll одна... а приложения запускаем два... уже получилась многопоточность...

Константин Хлопов

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

zahodun

для твоего случая... работает у меня подобная штука и на удивление стабильно и безотказно. Да и время очень жестко задано. В терх потоках живет (погоди всеж в четерех) общение с прогой по телнету, чтение данных с COM-порта каждые 100мс и общение с базой, которое может затянуться и на секунду и даже подольше... При том что результат чтения отображается в окне и в принципе я думаю можно редактирование прикрутить. А ларчик просто открывается. Например в потоке 1 тебе надо чтоб была форма (подчеркиваю это не главный поток в обычном понимании). Тогда ты именно в этом потоке создаешь форму (create) и в нем же даешь команду на отображение (show). Далее, дабы й тебя поток не прекратил свое существование слишком оперативно (то есть сразу после создания формы) оформляешь следующую последовательность команд:



синтаксис дельфей, но думаю переведешь. Sleep обязательно, дабы проток не грузил комп по напрасну. Можно этим спипом рулить приоритет своеобразно весьма. Разумеется, если мы завершаем поток, то необходимо убить форму. Точно так же можно создавать сколь угодно много форм. Причем разумеется в одном потоке. Объмен информацией между потоками я осуществляю через очередь. сразу предупрежу. Та что идет стандартно нельзя использовать, так как не поддерживает многопоточность. Я писал свою, если надо поделюсь, но разумеется написана на дельфе.
И в заключении скажу, что вся эта конструкция работает дополнительно и в dll и прекрасно функционирует.

датамодуль это просто контейнер и все. У него нет собственной очереди сообщений, поэтому вообще говоря не важно где его создавать. Я говорил все в отношении форм где и происходят все накладки при одновременном доступе из двух потоков. Если ты подменишь датамодуль на форму, то тут уже можно говрить осмыслено и в твоем случае форма окажется "привязана" к главному потоку. Привязана именно очередью.
Немного проясню откуда все траблы. Например мы пытаемся модифицировать label во втором потоке. При присваивании значения, оно автоматически отображается на форме и пишется в некую область памяти. В самый неприятный момент в очередь главного потока падает событие WM_PAINT, которое заставляет перерисоваться окно и соответственно и изменить информацию в той же самой области памяти, где и шарится второй поток. В итоге, происходят вещи, предсказать которые, крайне трудно.
Что происходит в случае когда окно создано и показано в коде второго потока? Ничего страшного кроме провязывания внутренних переменных библиотеки VCL и WinAPI. Когда же мы принудительно вызываем функцию ProgressMessages происходит обработка событий в очередях тех окон, которые созданы именно в этом потоке, откуда был вызов . В итоге, мы получаем, что работой окна управляет именнонаш вторичный поток и не касается его главный. Для доказательства, можно заблокировать цикл который я приводил, остановив тем самым второй поток. ОКНО ОБНОВЛЯТЬСЯ НЕ БУДЕТ Это я проверял и в принципе и дошел до этих идей именно через подобные тесты. (плюс хелп разумеется)

Теперь о твое проблеме. Рисуем в дизайнере нужную нам форму, со всеми элементами редактирования и прочего. Если нужен датамодуль, то можем создавать его где угодно(только разумеется он должен быть создан перед тем как его форма будет юзать, это важно отследить) либо в этой же форме. А потом создаем и показываем форму в функции потока. Все будет работать железно. Потому как это будет фактически однопоточник. Но я бы не советовал юзать компоненты, которые юзаются в форме в другом потоке. Иначе мы напоримся на те же грабли. Обмен можно осуществлять через очередь, но подчеркну еще раз стандартную очередь (компонента TQueue) использовать нельзя. Она не предназначена для обращения к ней из многих потоков, только внутри одного.

Сорри, наверное запутанно объяснил

1) На форме например объявлено Q:TIBQuery. Ты его юзаешь во втором потоке. Так вот в первом потоке не рекомендую обращаться к Q.

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

Не уверен что будет проще то что предлагает Roman Ignatiev ... В том что я предлагаю, ты можешь на форме делать все что угодно. Как в обычном приложении. В тоже время то что предлагается Романом надо будет отдельно отрабатывать для каждого запроса...

Константин Хлопов

критическая секция ставится для разграничения доступа к участку кода.
так что первый поток вычисляяет значение переменной и в критической секции присваивает это значение в буферную переменную . Второй поток (который оторажает данные) может функционировать например так: через определенное время в критической секции считывает значение из буферной переменной на экран . Вот и все

Это можно сделать и более чем просто
никаких траблов

// код функции вычисления чего-то долгоиграющего
...
result:=BigFunct;
EnterCriticalSection(CriticalSection);
buf:=result;
LeaveCriticalSection(CriticalSection);
...

// код функции отображения
...
EnterCriticalSection(CriticalSection);
Label1.Caption:=buf;
LeaveCriticalSection(CriticalSection);
...

и в чем проблемы?

а с какого счастья они будут? WM_PAINT может возникнуть когда угодно и будет прорисовывать данные из своих буферов. Даже если в самй протиыный момент, когда получаем результат функции... так тот результат попадает в буфер, а модуль отображения находится в том же самом потоке что и очередь сообщений.Между собой они разделены критической секцией... Вот и все

P.S. Прежде чем ввязываться в спор, нужно разбираться в этом

EnterCriticalSection(CriticalSection);
Label1.Caption:=buf;
LeaveCriticalSection(CriticalSection);

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

метод Synchronize... Ну не люблю я класс TThread... Органическое отвращение к нему... Тем более читал в литературе, что в нем есть ряд глюков... Так что юзайте WinAPI CreateThread

Именно про D6 разговор и велся, конкретно про функцию WaitFor.
В пятом (на котором работаю) мне не понравилась реализация метода Terminate.
а CreateThread это между прочим WinAPI... И именно через нее все и работает... в том числе и BeginThread. Причем вызывает она напрямую именно эту функцию

да и еще, исключения нужно вовремя перехватывать, особенн при работе с dll

function BeginThread(SecurityAttributes: Pointer; StackSize: LongWord;
ThreadFunc: TThreadFunc; Parameter: Pointer; CreationFlags: LongWord;
var ThreadId: LongWord): Integer;
var
P: PThreadRec;
begin
New(P);
P.Func := ThreadFunc;
P.Parameter := Parameter;
IsMultiThread := TRUE;
Result := CreateThread(SecurityAttributes, StackSize, @ThreadWrapper, P,
CreationFlags, ThreadID);
end;

это ее код )
и что тут высокоинтелектуального?

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

Все исключения и так у меня перехватываются (их попросту некому показывать на консоли сервера) да и вообще они должны перехватываться, чтобы не вгонять юзера в ступор непонятными фразами. Индикатор многопоточности... так я это и сам знаю , а VCL у меня работает в однопоточном режиме и так :))
Заменять процессами....
контекст процесса гораздо больше чем контекст потока и соответственно время на переключение так же. Синхронизация процессов несоизмеримо медленее синхронизации потоковну и плюс к тому общая память и соответственно обмен данными. Между процессами тоже можно подобное сделать, но это не так удобно и главное это медленно. Ну и последний довод. Если в windows есть понятие потока, значит он эффективнее, если приложение подразумевается как многопоточное, чем "многопроцессовое" приложение. Кстате, есть операционки где потоки отстутствуют как класс. Например QNX.