Работа с потоками с DCOM
У меня есть концептуальный вопрос о многопоточности:
В приложении, использующем RPC через DCOM, с конфигурацией многопоточных квартир, основная форма замораживается.
1 - Если CriticalSession создается при инициализации модуля, код в критическом сеансе будет выполняться в контексте основного потока?
2 - Когда вы вызываете метод для выполнения задачи:
Тема 1 создана. (Тема DCOM)
Поток 1 создает поток 2.
Нить 1 Ждем Нить 2.
Поток 2 создает 4 потока, чтобы выполнить задачу быстрее.
Нить 2 петли спит 2 секунды до конца 4 нити. В этих процессах основная форма должна обновляться для отображения процентов выполненных работ. В основной ветке формы публикуется сообщение с выполненным процентом, но ничего не происходит и основная форма замораживается.
3 - Есть ли лучший способ вместо метода synchronized() синхронизировать внутри одного из 4 потоков, когда им нужно CRUD (Create Read Update Delete) объекты в потоке 2?
4 - 4 потока имеют более высокий приоритет, чем основной поток, это проблема? Когда это станет проблемой?
Изображение ниже представляет архитектуру системы:
1 ответ
1: Нет. Используя критический раздел, вы гарантируете, что код выполняется только в одном потоке за раз; на практике любой поток, который вызывает Enter, будет зависать там до тех пор, пока любой другой поток, который также выполняет этот код, не попадет в вызов Leave. Но это не значит, что он будет работать в основном потоке (проверьте с помощью GetCurrentThreadID)
2: Вы упоминаете конфигурацию квартиры, но какая модель квартиры пронизывает? Это определяет, когда (D)COM будет выполнять синхронизацию потоков для вас. На практике COM будет работать с заглушками прокси и маршалингом за кулисами, чтобы пересекать границы квартир (и сетей), если только вы не выбрали многопоточную квартиру, и в этом случае COM будет предполагать, что компоненты сами решают проблемы с многопоточностью.
Если я правильно понимаю, основная форма зависает в "Thread 1 WaitFor Thread 2". Вместо вызова WaitFor вам лучше использовать событие OnTerminate в Thread2.
3: я не уверен, что вы подразумеваете под "объектами CRUD в потоке 2". Если не важно знать, в каком порядке заканчиваются 4 потока, я бы предложил вызвать WaitFor для потоков в последовательности. Если это так, вы должны проверить WaitForMultipleObjects.
4: Различные приоритеты не должны быть проблемой. Это может быть проблемой только тогда, когда слишком много высокоприоритетных потоков выполняет слишком много работы, поэтому потоки с обычным приоритетом, выполняющие внутреннюю связь, не успевают, но в этом случае вам следует проверить, как рабочие потоки сообщают о своей работе.