Синхронизация с основным тредом программы не из TThread

← →
Дмитрий Белькевич (2011-06-09 15:48) [0]

Добрый день. С синхронизацией из TThread, в целом, все понятно. Как сделать синхронизацию с основным тредом из треда, от которого есть только Idшник: GetCurrentThreadId?

← →
Дмитрий Белькевич (2011-06-09 15:56) [1]

Нашел классовую процедуру:

TThread.Synchronize(nil, SyncOnTrayLog);

так нормально будет работать?

← →
Eraser © (2011-06-09 17:16) [2]

вообще, как не единожды показа практика, такого рода синхронизаций, в т.ч. и из TThread лучше избегать, т.к. в итоге все равно придется переделывать потом по той или иной причине. чаще всего хватает OnTerminate или сообщений.

← →
misha_gr (2011-06-10 11:53) [3]

> вообще, как не единожды показа практика, такого рода синхронизаций, в т.ч. и из TThread лучше избегать

А можно поподробней?

← →
han_malign (2011-06-10 16:55) [4]

> от которого есть только Idшник: GetCurrentThreadId?

- ты вообще о чем? Что ты синхронизировать собрался - "Idшник"???
Какие данные принадлежащие основному потоку - изменяются в контексте твоего потока-призрака?

← →
Eraser © (2011-06-10 17:31) [5]

> [3] misha_gr (10.06.11 11:53)

Synchronize - прямой путь к дэдлокам и не очевидной логике работы программы.

← →
Юрий Зотов © (2011-06-10 18:05) [6]

Вообще, лучше, конечно, таких ситуаций изьегать (может быть, стоит пересмотреть логику программы?).

Но если уж очень надо, то можно попробовать так:

1. Найти поток по его ID.
2. Сделать ему suspend.
3. Синхронизироваться с главным потоком.
4. Сделать ему resume.

Но не факт, что это хороший способ. Лучше подумать, как бы этого избежать.

← →
Dimka Maslov © (2011-06-10 18:44) [7]

Для стандартных средств синхронизации абсолютно неважно какой поток с каким синхронизируется.

← →
oxffff © (2011-06-10 18:45) [8]

Вопрос не раскрыт. А так QueueUserAPC + Alertable state

← →
Dimka Maslov © (2011-06-10 18:48) [9]

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

← →
Loginov Dmitry © (2011-06-10 21:28) [10]

> Вопрос не раскрыт.

+1

Автору стоило бы более подробно раскрыть суть проблемы. На вопрос "как выполнить синхронизацию между потоками" я бы ответил "используй критические секции". Но поскольку не ясна цель синхронизации, невозможно что-либо посоветовать.

← →
Loginov Dmitry © (2011-06-10 21:35) [11]

> Вообще, лучше, конечно, таких ситуаций изьегать (может быть,
> стоит пересмотреть логику программы?).
>
> Но если уж очень надо, то можно попробовать так:
>
> 1. Найти поток по его ID.
> 2. Сделать ему suspend.
> 3. Синхронизироваться с главным потоком.
> 4. Сделать ему resume.

Юрий, suspend является deprecated начиная с D2010. Насколько я знаю, в некоторых из популярных языков программирования ситуация аналогичная (насколько помню и Java и .NET (возможно за исключением последних версий) в их числе). И deprecated оно стало не просто так, тому есть веские причины.

← →
jack128_ (2011-06-10 21:39) [12]

> Synchronize - прямой путь к дэдлокам и не очевидной логике
> работы программы.

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

← →
Юрий Зотов © (2011-06-10 23:40) [13]

> И deprecated оно стало не просто так, тому есть веские причины.

Какие?

Я придерживаюсь той точки зрения, что если человек умеет пользоваться инструментом, то этот инструмент ему вполне можно доверять. Ну а если не умеет, то он любым инструментом себе палец оттяпает.

← →
Loginov Dmitry © (2011-06-11 00:34) [14]

> Какие?

Менеджер памяти в многопоточном приложении синхронизирует операции распределения памяти. Для D7 - с помощью обычной критической секции, в более новых версиях используются другие способы синхронизации (более выгодные в плане производительности). В любом случае есть синхронизация, которая выглядит приблизительно так:
CriticalSection.Enter; try Код распределения памяти finally CriticalSection.Leave; end;

Представим себе следующий сценарий:
1. Поток "А" запросил выделение памяти. Сработал CriticalSection.Enter. Начал выполняться блок "Код распределения памяти".
2. Поток "В" в этот момент вызвал Suspend потоку "А".
3. Поток "В" запросил выделение памяти. Сработал CriticalSection.Enter. Однако к этому моменту поток "А" уже захватил критическую секцию CriticalSection.

В результате мы получим зависание приложения. Поток "В" никогда не дождется момента освобождения критической секции потоком "А", поскольку поток "А" остановлен (suspended) потоком "В".

Именно по этим причинам Suspended считается deprecated. Отладка многопоточного приложения в Delphi зачастую виснет, судя по всему, по аналогичным причинам.

На королевстве имеется замечательная статья, в которой все сказанное описано более подробно, с примерами (или с ссылками на примеры).

← →
Юрий Зотов © (2011-06-11 00:47) [15]

Следовательно, suspend надо сделать таким, чтобы он срабатывал только после выхода из критической секции. Но не запрещать совсем.

← →
Германн © (2011-06-11 01:50) [16]

> Следовательно, suspend надо сделать таким

Объявить deprecated проще.
Ведь сколько уже deprecated было в Дельфи.

← →
Eraser © (2011-06-11 03:42) [17]

> [12] jack128_ (10.06.11 21:39)

из опыта выделил. десятки ситуаций всяких. можно ли написать грамотный код, который будет работать как часы с помощью Synchronize? - Безусловно можно.

← →
Дмитрий Белькевич (2011-06-12 01:10) [18]

> Автору стоило бы более подробно раскрыть суть проблемы.

Уточняю. Вопрос возник по вот этой причине:

http://delphimaster.net/view/10-1306751915/

>Пытаюсь вызывать из COM сервера процедуру клиента (Events). Когда вызываю из основного потока (с помощью метода Synchronize) - то все происходит нормально - вызов приходит на сторону клиента. Когда же вызов идёт из неоснового потока - событие клиент не получает.

>DiamondShark © (01.06.11 11:57) [1]
>В неосновном потоке, конечно же, цикла выборки сообщений нет.

То есть - мне нужен аналог Synchronize для потоков, к которым я не могу обратиться как к TThread"у.

Похоже, что TThread.Synchronize(nil, SomeMethod) делает то, что нужно.

← →
sniknik © (2011-06-12 01:38) [19]

>> В неосновном потоке, конечно же, цикла выборки сообщений нет.

> То есть - мне нужен аналог Synchronize для потоков, к которым я не могу обратиться как к TThread"у.

?????????????????????

синхронизация потоков с циклом выборки и рядом не лежала...

← →
Дмитрий Белькевич (2011-06-12 10:45) [20]

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

Вообще - как связаны сообщения с событиями (Events) COM сервера я так и не нашел, возможно есть какие-то более изящные механизмы доступа к событиям сервера, чем Synchronize.

В любом случае - спасибо всем ответившим.

← →
sniknik © (2011-06-12 10:55) [21]

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

← →
Loginov Dmitry © (2011-06-12 17:56) [22]

> Следовательно, suspend надо сделать таким, чтобы он срабатывал
> только после выхода из критической секции. Но не запрещать
> совсем.

Тогда придется реализацию suspend делать в менеджере памяти. Вряд ли пойдут на это. Да и смысла нет.

← →
Loginov Dmitry © (2011-06-12 17:57) [23]

> Объявить deprecated проще.

Гораздо проще. Настолько просто, что и Resume досталось. Имхо, незаслуженно.

← →
Loginov Dmitry © (2011-06-12 18:11) [24]

> Уточняю. Вопрос возник по вот этой причине:
>
> http://delphimaster.net/view/10-1306751915/
>
> >Пытаюсь вызывать из COM сервера процедуру клиента (Events).
> Когда вызываю из основного потока (с помощью метода Synchronize)
> - то все происходит нормально - вызов приходит на сторону
> клиента. Когда же вызов идёт из неоснового потока - событие
> клиент не получает.
>

Засовывать DCOM в службу, имхо, не самое удачное решение. DCOM, как показывает многолетняя практика, не самая удачная технология. Почему бы Вам не реализовать службу, к примеру, через Indy компоненты (TIdTCPServer / TIdTCPClient) (вполне себе проверенное решение с минимальным количеством подводных камней).

← →
Дмитрий Белькевич (2011-06-12 19:43) [25]

> Засовывать DCOM в службу, имхо, не самое удачное решение.
> DCOM, как показывает многолетняя практика, не самая удачная
> технология. Почему бы Вам не реализовать службу, к примеру,
> через Indy компоненты (TIdTCPServer / TIdTCPClient) (вполне
> себе проверенное решение с минимальным количеством подводных
> камней).

Сложности реализации меня не беспокоят - рано или поздно разберусь. Главное - что бы пользователям систему настраивать, по возможности, не пришлось.

← →
Loginov Dmitry © (2011-06-12 19:55) [26]

> Главное - что бы пользователям систему настраивать, по возможности,
> не пришлось.

Настройку DCOM никак нельзя назвать легкой. Намного проще написать инструкцию в пару строк о добавлении приложения в список исключений файрволла, чем целую диссертацию о настройках DCOM"а. В простейшем случае настраивать ничего не нужно. Но когда дело дойдет до настройки, тут можно лоб сломать и мозг вывихнуть. Вот один из примеров руководства по настройке DCOM: http://clck.ru/Ece6
Как Вам?

← →
Дмитрий Белькевич (2011-06-13 12:40) [27]

> Как Вам?

Посмотрел. Ад, конечно. Но - у меня более простой случай - локальное соединение, есть надежда, что в большинстве случаем будет работать сразу.

← →
Дмитрий Белькевич (2011-06-13 12:42) [28]

Еще мысль, ведь наверняка можно настройку автоматизировать. Сделать какой-то софт, который всё, что описано в документе http://clck.ru/Ece6 будет делать сам. Имея права, само собой.

← →
sniknik © (2011-06-13 14:23) [29]

> будет делать сам.
чуть "докрутишь" и готов искусственный интеллект... и нафига тебе "базовая" программа? бросай ее, займись сразу тем, что выгоднее. ("базовую" он тебе потом сам напишет...)

p.s. ты из простой вещи сделал сложную... думаешь осилишь сложное не превратив его в невозможное?

← →
Дмитрий Белькевич (2011-06-13 15:39) [30]

> чуть "докрутишь" и готов искусственный интеллект...

Какой там интеллект, если по пунктам всё в мануале настройки расписано?

> p.s. ты из простой вещи сделал сложную... думаешь осилишь
> сложное не превратив его в невозможное?

Не понял о чем речь. В любом случае - байты везде одинаковые, и компьютер в принципе познаваем.

← →
sniknik © (2011-06-13 17:03) [31]

> Какой там интеллект
замена админа программой...

> если по пунктам всё в мануале настройки расписано?
а почему у них не программно? если все так просто. и как будет делаться настройка прав, вернее зачем, если права уже есть
> Имея права, само собой.
и как, если их нет.

> Не понял о чем речь. В любом случае - байты везде одинаковые, и компьютер в принципе познаваем.
он познаваем... но не в том случае когда решая, что то конкретное, придумывают что-то абстрактное, и начинают это усиленно "познавать" ака выдумывать себе еще глуп... абстракций.

вот вернись к тому с чего начал,
> Уточняю. Вопрос возник по вот этой причине:
> http://delphimaster.net/view/10-1306751915/
и скажи зачем ты приплел к этому синхронизацию. если там тебе сказали не работает из-за отсутствия цикла выборки.
???

← →
Дмитрий Белькевич (2011-06-13 23:51) [32]

> а почему у них не программно?

Кто же знает - кому-то удобнее мануалы выпускать, чем программы. Мы стараемся сделать так, что бы пользователи минимально настраивали программы, насколько это возможно. Другие (точно знаю: так делают наши прямые российские конкуренты, не буду говорить, кто именно) умышленно делают программы так, что бы без их сервиса настроить (почти) невозможно было. У каждого свой подход.

> и как, если их нет.

RunAs.

> и скажи зачем ты приплел к этому синхронизацию. если там
> тебе сказали не работает из-за отсутствия цикла выборки.
>

Работает, если сделать Synchronize.

← →
sniknik © (2011-06-14 00:35) [33]

> RunAs.
смешно... буду теперь так админов у себя звать.

> Работает, если сделать Synchronize.
в основном потоке цикл есть. и что? зачем тебе тогда поток?, если из-за цикла (мелочи в общем то) все "одеяло" туда перетягиваешь... работай тогда всегда в основном да и не парь мозг.

никакие сообщения, критические секции и т.д. аналоги, тебе тогда не пойдут, мог бы и не спрашивать "как лучше", только "переключение на работу в основном"...
т.е. идеал у тебя будет "шпыняемый" всеми пример Архангельского... (ну там где вся работа е в синзхроне), ни и, что, что тормозит типа, зато потоки используем...

← →
Германн © (2011-06-14 02:13) [34]

> т.е. идеал у тебя будет "шпыняемый" всеми пример Архангельского.
> .. (ну там где вся работа е в синзхроне), ни и, что, что
> тормозит типа, зато потоки используем...

Таки да.

← →
Дмитрий Белькевич (2011-06-14 09:00) [35]

> смешно... буду теперь так админов у себя звать.

Если прав нету - то и мануал никак не поможет. Если права есть - и программа справится.

> в основном потоке цикл есть. и что? зачем тебе тогда поток?
> , если из-за цикла (мелочи в общем то) все "одеяло" туда
> перетягиваешь... работай тогда всегда в основном да и не
> парь мозг.

Обращение через основной поток к событиям COM занимает у меня от силы доли процента времени работы дополнительных потоков.

> т.е. идеал у тебя будет "шпыняемый" всеми пример Архангельского.
> .. (ну там где вся работа е в синзхроне), ни и, что, что
> тормозит типа, зато потоки используем...

Я же спрашиваю про варианты. Никто ничего другого пока не предложил. Найду что-то лучше - сделаю по-другому. Пока что оставлю как есть.

p.s. Подумалось... События через механизмы COM всё равно же будут последовательно проходить? То есть - куча потоков одновременно "ломятся" послать событие, но, как ни крути, единомоментно COM передаёт только одно событие. Если так, то что ни делай - быстрее не будет. Так как узкое место - не синхронизация с основным потоком.

← →
Дмитрий Белькевич (2011-06-14 09:03) [36]

> т.е. идеал у тебя будет "шпыняемый" всеми пример Архангельского.
> ..

Всё таки удивительно, как люди дистанционно пытаются ставить кому-то диагнозы и говорить за других. Роды по интернету, чесслово.

← →
Дмитрий Белькевич (2011-06-14 09:03) [37]

Пишу же:

"Все события клиента нужно обязательно синхронизировать? Или можно как-то без этого обойтись?"

← →
Дмитрий Белькевич (2011-06-14 09:16) [38]

В этой же ветке, на найдя лучшего решения, спрашиваю совсем о другом:

"Как сделать синхронизацию с основным тредом из треда, от которого есть только Idшник: GetCurrentThreadId?"

Конкретный же вопрос. Ну нету у меня инстансов класса TThread в некоторых местах программы, что бы из этих инстансов синхронизироваться. Хорошо, что класс TThread умеет переключаться на основной поток, даже без собственного инстанса, без Self"а.

>вообще, как не единожды показа практика, такого рода синхронизаций, в т.ч. и из TThread лучше избегать, т.к. в итоге все равно придется переделывать потом по той или иной причине. чаще всего хватает OnTerminate или сообщений.

Хорошо, отказываемся от Synchronize, делаем сообщение. Что это меняет? Учитывая, что мне нужно синхронно послать сообщение COM клиенту и дождаться от него ответа в виде результат обработки этого сообщения?

← →
sniknik © (2011-06-14 09:43) [39]

> единомоментно COM передаёт только одно событие.
если один экземпляр, "апартмент" тип вроде то да, но "мульти" это отдельный инстанс в каждом потоке/подключении.

> Так как узкое место - не синхронизация с основным потоком.
естественно не она, она вообще не нужна. нужен цикл выборки.

> Всё таки удивительно, как люди дистанционно пытаются ставить кому-то диагнозы и говорить за других. Роды по интернету, чесслово.
вел бы себя по адекватнее, решал бы именно проблему/по подсказаному (либо сказал почему это не подходит), а не придуманное на ее основании. глядишь родов бы и не было...

> В этой же ветке, на найдя лучшего решения, спрашиваю совсем о другом:
не найдя? а ты пробовал???!!! тебе там прямым текстом, разве, что не код дали, и не найдя? прям матом хочется разговаривать...

> Учитывая, что мне нужно синхронно послать сообщение COM клиенту и дождаться от него ответа в виде результат обработки этого сообщения?
раз синхронно, и дождаться + в потоке, нафига вообще события? прямой вызов функции и синхронно и ждет, и результат сразу...
хотя, да понимаю, с учетом моих домыслов (инет родов) у тебя же основной поток виснет... да?

> Конкретный же вопрос.
без кода? это тебе только так кажется, что конкретный.

← →
Дмитрий Белькевич (2011-06-14 19:29) [40]

> если один экземпляр, "апартмент" тип вроде то да, но "мульти"
> это отдельный инстанс в каждом потоке/подключении.

У меня всегда может существовать только один инстанс сервера и клиента - это связка сервис-гуй - COM сервер (сервис) + иногда подключающийся COM клиент - гуй. То есть, как я понимаю, всегда будет один поток данных.

Или связка COM клиент-сервер создаётся на каждый поток приложения?

> прямой вызов функции и синхронно и ждет, и результат сразу.
> ..

Как на стороне сервера вызвать функцию клиента? Кроме событий я ничего не нашел.

Сейчас работает так:

COM сервер имеет COM интерфейс, через который его функции вызывает COM клиент.
COM сервер же через Events обращается к функциям клиента.

← →
Eraser © (2011-06-14 19:48) [41]

> Дмитрий Белькевич

вопрос. какой именно функционал надо реализовать? т.е. какова задача?

← →
sniknik © (2011-06-14 20:35) [42]

> Или связка COM клиент-сервер создаётся на каждый поток приложения?
само по себе ничего не создается, и то что ты в программе сделал хоть сто потоков, ни одного не создаст...

тебе не надоело абстракциями "швыряться"? мне попусту молоть уже да...

> Как на стороне сервера вызвать функцию клиента?
коллбек

> т.е. какова задача?
он считает, что уже все описал... -
>> Конкретный же вопрос.
при том, что методы о которых расспрашивает в ветке(2-х) уже раза четыре кардинально поменялись...

← →
Дмитрий Белькевич (2011-06-14 23:11) [43]

> вопрос. какой именно функционал надо реализовать? т.е. какова
> задача?

Есть некоторое количество функций в сервере и в клиенте, которые должны вызываться клиентом и сервером.

Действие первое. Сервер вызывает процедуру клиента. Клиент через var параметр синхронно возвращает результат вызова.

Действие второе. Клиент вызывает функцию сервера. Сервер возвращает результат функции.

Все действия независимы, их несколько разных - штук 30 первых и штук 40 вторых. Действия от клиента могут вызывать ответные действия от сервера до окончания вызова от клиента. Некоторые из первых действий идут из разных потоков, вторые идут из главного потока. Траффик как по вызовам, так и по объему данных, в обе стороны незначительный.

> он считает, что уже все описал... -

Я считаю, что задал достаточно конкретный первый вопрос. То, что все менялось - результат продолжения обсуждения вопроса в com/corba. Который там обсуждать никто не хотел (это я не предъявляю, просто констатирую - нету времени у людей, и мне никто не должен, я понимаю).

← →
Дмитрий Белькевич (2011-06-14 23:14) [44]

>Все действия независимы

в том смысле, что может одновременно (из разных тредов) прийти несколько первых действий.

← →
Eraser © (2011-06-14 23:23) [45]

> [43] Дмитрий Белькевич (14.06.11 23:11)

Оно конечно красиво звучит - "клиент вызывает код сервера". Но вот я бы лично такое реализовывать никогда бы не стал. Разве что, ради спорт. интереса. Оставим эту прерогативу монстрам типа MS. Не проще ли сделать обычный TCP или Named Pipe обмен данными? Если рассуждать более глобально, то я вообще не вижу смысла в нашу эпоху все строить исключительно на технологиях MS. А вдруг завтра клиент под айфон срочно писать, что тогда? Правильно - сервер тоже переписывать.

← →
Дмитрий Белькевич (2011-06-14 23:36) [46]

> Правильно - сервер тоже переписывать.

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

> то я вообще не вижу смысла в нашу эпоху все строить исключительно
> на технологиях MS.

Да я и сам стараюсь максимально обходится без технологий MS, насколько это возможно и оправдано.

← →
sniknik © (2011-06-14 23:39) [47]

> Который там обсуждать никто не хотел ...
там тебе ОТВЕТИЛИ..., что ты проигнорировал, и начал нести свою "правду матку", в ответ проигнорировали тебя.

← →
Дмитрий Белькевич (2011-06-14 23:48) [48]

> и начал нести свою "правду матку"

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

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

ничего не напоминает?

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

и кстати ты проигнорировал мой ответ, про коллбеки (хоть что-то конкретное, среди абстракций, было на что ответить можно)...
вот +
http://www.rsdn.ru/article/db/callback.xml
и в общем то нафиг, эту ветку, уже тоже раздражать начинает. талант.

> По хорошему-то, конечно, было б неплохо на трубы или сеть
> переползти, но возни много с параметрами, с синхронизацией
> ответов.

Имхо, тут непродуман некий "транспортный протокол". Оттуда ноги растут. И совсем не важно на какой основе сей "транспорт" реализован. И "синхронизация" тут тоже совсем не та, которая Synchronize.

> хочется быстрое решение

DCOM это быстрое решение?! да это думаю самое сложное решение из множества возможных.
На обычных Indy компонентах можно весьма быстро навоять универсальный многопоточный полнодуплексный транспорт сообщений. Для синхронизации с основным потоком можно делать выборку из очереди принятых по таймеру. Короче задача на пол дня, даже если не знаком с этими компонентами. Зачем же лезть в такие дебри как DCOM для простейших вещей.

← →
Дмитрий Белькевич (2011-06-15 23:43) [52]

> это ты вообще о чем? какая связь, из какого пальца синхронизацию
> высосал? и т.д. если бы была логическая цепочка процесса
> в твоей голове - "цикл выборки, как понял это синхронизация?
> т.к. выполнил код в ней и он заработал. значит нужно обязательно
> синхронизировать?"

Я понял, почему не работало. Собственно - написали - нет цикла сообщений. Спросил. Можно ли что-то сделать кроме синхронизации:

"Все события клиента нужно обязательно синхронизировать? Или можно как-то без этого обойтись?"

То есть - синхронизация с основным тредом - это единственно возможное решение? Или еще что-то возможно предпринять? В ответ - тишина.

После этого попытался выяснить каким боком вообще сообщения с COM связаны (кстати, до сих пор не знаю). Какое именно сообщение шлется основному потоку во время вызова COM Events в Synchronize? Кто это сообщение шлет? Какие параметры? Кто это сообщение позже обрабатывает?

> и кстати ты проигнорировал мой ответ, про коллбеки (хоть
> что-то конкретное, среди абстракций, было на что ответить
> можно)...

спасибо, посмотрю.

> И "синхронизация" тут тоже совсем не та, которая Synchronize

Само собой:

> DCOM это быстрое решение?!

Да.

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

С tcp то же самое - через один порт параллельно несколько сообщений не передашь - только если несколько соединений делать. Всё равно возвращаемся к сериализации запросов в обе стороны - никаких преимуществ по сравнению с тем, как уже сделано (ну разве что не будет привязки к COM). Несколько портов - хорошо, если они все будут свободными, если нет - придётся искать свободные. Ну это то, что сразу могу придумать, что придется обрабатывать.

> Короче задача на пол дня

Увы, я не на столько крут :) Хоть и с компонентами знаком.

> Несколько портов - хорошо, если они все будут свободными,
> если нет - придётся искать свободные.

А Вы считаете, что с DCOM ситуация лучше?
Дело до маразма доходит. DCOM выделяет прослушивающий порт случайным образом из некоторого (заранее неизвестного!) диапазона (якобы этот диапазон можно настраивать, но об этом я пока слышал только в теории). Это сделано с целью усиления защиты (хакеру трудно предугадать, какой набор портов используется в тот или иной момент DCOM-ом). Из-за этого невозможно настроить файрволл должным образом! DCOM-зло! Если этой поделкой пользуется MS, это не значит, что всем следует этим пользоваться.
Кстати Вы в курсе, что DataSnap в последних версиях Delphi уже не завязано на DCOM?

> С tcp то же самое - через один порт параллельно несколько
> сообщений не передашь

А через что можно передать "параллельно несколько сообщений"?
Через DCOM? Ты либо бредишь, либо партизанишь.

если строго параллельно нужно передавать несколько сообщений, то скорее всего, ну в 95% случаев, нужно менять архитектуру. Насчет DCOM - есть еще такая замечательная вещь, как UAC и терминальные сессии. Короче, как говорится, не говорите потом, что я не предупреждал ;-)

> если строго параллельно нужно передавать несколько сообщений

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

> Я понял, почему не работало. Собственно - написали - нет цикла сообщений. Спросил. Можно ли что-то сделать кроме синхронизации:
понял? сомневаюсь... фразы строишь так как будто об одном и том же говоришь, а это РАЗНЫЕ вещи. и спрашиваешь дальше не о цикле, его ты игнорируешь, а о синхронизации.

типа
- я голоден.
- есть не пробовал?
- все поставленное на стол нужно выпить? нельзя без этого обойтись?
(жена ругает/с пол литры дурной становишься, и т.д. плевать на причины, сколько не обсуждай их потом/узнавай как "правильней", без болезненней, это НЕ ТО о чем тебе говорили изначально.)

p.s. вот как такой простой вещи не понять (РАЗНЫЕ!)... впечатление, как об стенку горох. глухо.

> В ответ - тишина.
я его понимаю... понять бессмысленность дальнейших объяснений по одной ответной реплике, и остановиться... тоже талант нужен.

← →
Дмитрий Белькевич (2011-06-16 09:48) [58]

> А через что можно передать "параллельно несколько сообщений"?
> Через DCOM? Ты либо бредишь, либо партизанишь.

Из того, что мне пытается объяснить sniknik, я делаю вывод - что да. Иначе я текущую реализацию трогать не буду, если всё равно всё в сериализацию запросов упрется.

← →
Дмитрий Белькевич (2011-06-16 10:31) [59]

> если строго параллельно нужно передавать несколько сообщений,
> то скорее всего, ну в 95% случаев, нужно менять архитектуру.
>

Мне - не нужно, мне пытаются объяснить, что так - единственно хорошо. Меня, в общем, и последовательные запросы устраивают вполне. Треды немного подождут - не беда.

> Из того, что мне пытается объяснить sniknik, я делаю вывод - что да.
из какого места выводы?
я то думал, что объясняю разницу между решением проблемы, и решением "миража проблемы". впрочем... бессмысленно. нет даже первого шага - осознания, что разница вообще есть.

к тому же, если по мне, то решать нужно задачу а не проблемы на пути к ее решению... тут же вообще проблема выдумана (без кода это конечно догадки, предположения), но вот, что "имеем" взят COM/DCOM с событиями, то что по логике не требует потоков, просто даешь команду, оно выполняет независимо от тебя, по окончанию сигнализирует, обрабатываешь сигнал... все. эту событийную модель "ломают" под свое разумение т.к. "нужно ждать ответа" (кому нужно? это же логика, а не указ. ну да ладно), дальше "проблема", в основном потоке это "вешает" интерфейс... начинают "решать" пихают "систему" в поток... возникает вторая "проблема" поток "не ловит событий"... не разбираясь, и не даже пытаясь понять явную подсказку... "решили" "проблему" "выдавив" отлавливание события в основной поток, просто потому что "раз так работает, значит это то про, что сказали (цикл выборки)", теперь проблему уже не мелочах, теперь уже идеология, у человека (грубо) "еда" ассоциируется с "закусью при выпивке"... и т.д. ком проблем "из ничего". просто потому, что изначально выбрана не та модель/логика, что нужна (или вернее наоборот. не поняв "событийную логику" человек начал ее "ломать" вместо изучать, и понимать...)

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

болтология одна, давно пора в потрепаться...

← →
Дмитрий Белькевич (2011-06-16 11:03) [61]

> из какого места выводы?

>> единомоментно COM передаёт только одно событие.
>если один экземпляр, "апартмент" тип вроде то да, но "мульти" это отдельный инстанс в каждом потоке/подключении.

> т.к. "нужно ждать ответа" (кому нужно? это же логика, а
> не указ. ну да ладно),

Нужно по логике работы программы. Да, она не асинхронно-событийная, она синхронная, так исторически сложилось.

> дальше "проблема", в основном потоке это "вешает" интерфейс.
> ..

Я такого нигде не писал, у меня этой проблемы нет.

> начинают "решать" пихают "систему" в поток

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

> просто потому что "раз так работает, значит это то про,
> что сказали (цикл выборки)",

Просто потому, что как ни сделай - всё равно так получится. В том смысле - что даже если я буду двигаться в направлении работы с циклом выборки - это ничего принципиально не изменит. Если COM сериализует вызовы.

> просто потому, что изначально выбрана не та модель/логика,
> что нужна (или вернее наоборот. не поняв "событийную логику"
> человек начал ее "ломать" вместо изучать, и понимать...)

Да знаю я событийную логику. Я понимаю, что русские любят всё переписывать с нуля, вместо того, что бы решать задачи минимальной кровью. Ну на кой ляд мне перелопачивать тысяч 200 строк кода, если и так всё работает как нужно? Только ради принципа "не так как у Архангельского"?

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

>> единомоментно COM передаёт только одно событие.
>если один экземпляр, "апартмент" тип вроде то да, но "мульти" это отдельный инстанс в каждом потоке/подключении.
10 одновременно работающих экземпляров COM объекта трудно представить? а одновременно передаваемых от них событий? без демагогий о том что "на самом деле они не одновременные, а последовательные" просто событие либо ждет в очереди обработки предыдущего, либо получается инициировавшим его потоком.

> Нужно по логике работы программы. Да, она не асинхронно-событийная, она синхронная, так исторически сложилось.
тогда почему проигнорирован совет не пользоваться в потоках событийной моделью а просто сделать прямой вызов функции с возвратом из нее результата?

> Только ради принципа "не так как у Архангельского"?
ради принципа - "неправильное сделать правильным, или в корзину его". если работает и устраивает то в ж... принципы, просто не трогай работающее.

> разделить одно приложение на два - гуй + сервис.
удачи. она тебе понадобится.

> Сейчас задача - с минимальными временными затратами и минимальными
> переделками разделить одно приложение на два - гуй + сервис.
>

Для чего? Чем не устроило простое DCOM-приложение так, что потребовалось разбивать его на DCOM-приложение-сервис и интерфейс пользователя.
Кстати, на чем реализован DCOM-сервис? Случайно не через исходники службы "Borland Socket Server"? Если так, то от DCOM остается лишь одно название, получаем обычный TCP/IP.

> [61] Дмитрий Белькевич (16.06.11 11:03)

> гуй + сервис.

даже в ОС для этого используются именованные каналы.

← →
Дмитрий Белькевич (2011-06-19 11:56) [65]

> Чем не устроило простое DCOM-приложение так, что потребовалось
> разбивать его на DCOM-приложение-сервис и интерфейс пользователя.
>

Изначально приложение не было вообще DCOM. Изначально было просто обычное приложение - сервер. Который до win 2003 server можно было запустить как сервис (с помощью отдельной тулзы), взаимодействующий с пользователем. Всё всех устраивало и работало нормально. В 2008-м сервере от взаимодействия сервисов с пользователем отказались. Сервис взаимодействовать-то взаимодействует, только показывает всё на отдельном десктопе. Приходится разбивать приложение на два. Я не говорю, что это плохо (для буквоедов и иже), ну только что - лишняя возня.

> даже в ОС для этого используются именованные каналы.

Все меня так активно отговаривают от DCOM, почитал я ужасы DCOM в интернетах (Loginov Dmitr"ия в частности), что я опять на SOAP смотрю. Свой транспорт писать не хочу.

← →
Дмитрий Белькевич (2011-06-19 12:01) [66]

Интересно как у SOAP с двухсторонним общением...

> Все меня так активно отговаривают от DCOM, почитал я ужасы
> DCOM в интернетах (Loginov Dmitr"ия в частности), что я
> опять на SOAP смотрю.

От DCOM"а никто не отговаривает. Если приложение уже написано и работает, то менять что-то из-за вычитанных "ужасов" - нецелесообразно. Но при разработке нового приложения я бы рекомендовал учитывать мнения, здесь высказанные.

← →
DCOM (2011-06-19 17:04) [68]

DCOM<>COM

Синхронизация с основным тредом программы не из TThread Найти похожие ветки