Работа с потоками с DCOM

Question

У меня есть концептуальный вопрос о многопоточности:

в приложении с помощью RPC через DCOM, с многопоточной конфигурации, кухня объединена с основной формой замерзает.

1 - Если CriticalSession создается при инициализации устройства, код в критическом сеансе будет выполняться в контексте основного потока?

2 - Когда вы вызываете метод для выполнения задачи:
Тема 1 создана. (DCOM Thread)
Резьба 1 создает нить 2.
Тема 1 WaitFor Thread 2.
Резьба 2 создает 4 потока, чтобы быстрее выполнять задачу.
Резьба 2 петли спать 2 секунды до конца 4 потоков. В этих процессах основная форма должна быть обновлена, чтобы отобразить процент выполненных действий. Сообщение отправляется в основной поток формы с процентом, но ничего не происходит, и основная форма замораживается.

3 - Вместо синхронного() метода лучше всего синхронизировать внутри одного из 4 потоков, когда им нужно создать объекты CRUD (Create Read Update Delete) в Thread 2?

4 - 4 темы имеют более высокий приоритет, а основной поток - это проблема? Когда это станет проблемой?

Изображение ниже, представляют архитектуру системы:

Answer 1

1: Нет Используя cricital раздел, вы гарантируете, код выполняется в только один нить в то время; на практике любой поток, который вызывает Enter, будет повесить там, пока ни один другой поток, который также запускает этот код, не попадает в вызов Leave. Но это не означает, что он будет работать в основном потоке (проверьте с помощью GetCurrentThreadID)

2: Вы упомянули конфигурацию квартиры, но какая модель резьбы по квартире? Это определяет, когда (D) COM будет сделать синхронизацию потоков для вас. На практике COM будет работать с прокси-заглушками и сортировать за кулисами до траверс границы квартиры (и сети), если вы не выбрали многопоточную квартиру, и в этом случае COM предположит, что компоненты сами позаботятся о проблемах с потоками.

Если я правильно понимаю, основная форма замерзает на «Thread 1 WaitFor Thread 2». Вместо вызова WaitFor вам будет лучше использовать событие OnTerminate в Thread2.

3: Я не уверен, что вы подразумеваете под «объектами CRUD в Thread 2». Если не важно знать, в каком порядке заканчивается 4 потока, я бы предложил вызвать WaitFor по потокам в последовательности. Если это так, вы должны проверить WaitForMultipleObjects.

4: Различные приоритеты не должны быть проблемой. Это может быть проблемой, когда слишком много высокоприоритетных потоков выполняют слишком много работы, поэтому потоки с нормальным приоритетом, выполняющие внутреннюю связь, не могут идти в ногу, но в этом случае вам следует просмотреть, как рабочие потоки сообщают о своей работе.