Многопоточность, структура простой программы.


Задача (упрощённо)

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

Я хотел уточнить, в первом приближении структура проги в плане потоков должна быть такая:

-Основной поток (форма);
-Поток шедуллера;
-Поток выполнения задачи.
?

Если так, то вопрос, поток выполнения задачи должен создавать шедуллер? (хотя, имхо, это не принципиально)

С потоками общался, но они всегда были одноразовые, т.е. нажал кнопку, поток создался, отработал, отрубился. А тут получается, что постоянно должны быть запущено несколько потоков.
Если принципиально, использую BCB или Delphi (еще не решил), планирую использовать стандартный TThread&VCL.

Имхо, всё что нужно сделать в таком случае:
- создать WinAPI-шное событие
- создать поток шедулера и передать ему хендл события через параметр
- в потоке шедулера сделать бесконечный цикл с ожиданием события (по типу worker thread)

Вот пример:

Цитата

// наш поток DWORD WINAPI MyThreadProc(LPVOID lParam) {     HANDLE hEvent = (HANDLE) lParam;     while(1)     {         if(WaitForSingleObject(hEvent, INFINITE) == WAIT_OBJECT_0)         {                            // какие-то действия потока при наступлении события         }     }     return 0; } // заголовочный файл формы class TForm1: public TForm {      ...      HANDLE   m_hEvent;      ... }; // какой-нибудь обработчик, вызываемый при создании формы void  TForm1::FormActivate() {     ...     m_hEvent = ::CreateEvent(0, FALSE, FALSE, NULL);     DWORD dwThreadId;     ::CreateThread(0, 0, &MyThreadProc, (LPVOID)m_hEvent, 0, &dwThreadId);     ... }

- для генерации события (и вызова соответствующих действий в потоке) достаточно в любом месте вызвать ::PulseEvent(m_hEvent)

P.S. Сорри за возможные неточности при описании класса и метода формы -- я не очень дружу с BCB.

Это сообщение отредактировал(а) mr.DUDA - 21.12.2003, 20:24

Цитата(mr @ 21.12.2003, 20:20)

- создать WinAPI-шное событие

Спасибо!

вопрос: а для чего это делать через событие, ведь можно сделать через внутренюю переменную программы?

ещё вопрос:
а где-либо есть дока, которая описывает общие принципы построения многопоточных программ? Я поискал, но не нашёл

Для синхронизации есть много всяких хреней (мьютексы, семафоры, события). Если поток один, то можно использовать и переменную (я раньше сам так делал), но встроенные объекты синхронизации более оптимизированы для многопоточной работы и, например, приложение с тремя потоками кроме основного синхронизацию делало лучше посредством встроенных объектов. В твоем случае, мне кажется, проще будет просто зарядить виндовский таймер на то значение, какое тебе нужно и ловить WM_TIMER в главном окне. Тогда и потоков не понадобится. Если все-таки будешь делать через потоки, то документация есть в MSDN:Platform SDK\Windows Base Service\DLL, Processes and Threads.

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

Это сообщение отредактировал(а) zemfir - 21.12.2003, 22:38

Согласен с Jcs. В сформулированной задаче необязательно городить много потоков, а то и вообще обойтись двумя однопоточными приложениями: Если точность шедулера не должна быть лучше секунды, то раз в секунду, например, по сообщению от таймера проверяем время и при необходимости запускаем отдельный процесс по выполнению задачи. Это никак не будет тормозить пользовательский интерфейс. Если нужно получать информацию об окончании выполнения, то проверяем WaitForSingleObject для созданного процесса с нулевым временем в том же обработчике таймера.

Цитата(Ars @ 22.12.2003, 12:10)

Согласен с Jcs. В сформулированной задаче необязательно городить много потоков

Спасибо! У меня встречный вопрос, интересно, а с точки зрения правильности программы:

-главная форма, в ней таймер,
-открыл модальное окно,
-В главном окне таймер продолжает тикать и что-то выполняется.

Это нормально?

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

Пока модальное окно не закрыто, управление в вызывающюю функцию не возвращается. Соответственно, сообщения родительского окна не обрабатываются. Это, конечно, может стать помехой в работе шедулера, но решаемо. Во-первых, можно вытаскивать из очереди приложения и обрабатывать сообщения от таймера и во время работы модального окна, во-вторых, - не использовать модальные окна.

Ars
Если брать VCL таймер в главной форме, то он будет работать и при открытом модальном окне и при этом будет выполняться его обработчик.
Меня интересует на сколько это корректно.

А почему это некорректно? Если это работает, значит это корректно

Цитата(Ars @ 22.12.2003, 14:04)

А почему это некорректно? Если это работает, значит это корректно

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

В общем, буду дальше разбираться;)
Спасибо!