forum.clarionlife.net

В простейшем виде все выглядит так:
Поток 1 - клиент, содержит клиентские классы для серверов 1, 2, n
Поток 2 - сервер 1
Поток 3 - сервер 2
...
Поток n - сервер n

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

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

StillZero писал(а):PostMessage поможет, это да...
задача абстрактно описана, и, насколько я понял, самодельная... странно, что сервера работают в разных потоках, а клиент в одном... и сделайте клиентов тоже в разных потоках, тогда и кларин POST прокатит

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

за PostMessage спасибо, попробую порыть в эту сторону

vd-vuf писал(а): Как еще можно можно пустить сообщение точно в цель?

А решение Издатель- Подписчик (Publisher - Subscriber) не устроит?
Подписчик принимаети все сообшения, а реагирует только на те, нак которые подписан.

А всё это локально?

С уважением,
Bruce

Bristan писал(а):

vd-vuf писал(а): Как еще можно можно пустить сообщение точно в цель?

А решение Издатель- Подписчик (Publisher - Subscriber) не устроит?
Подписчик принимаети все сообшения, а реагирует только на те, нак которые подписан.

А всё это локально?

С уважением,
Bruce

собственно этот обмен нужен внутри приложения. PostMessage заюзал, сильно выручило.
обимен проходит на ура, избавился от ICriticalSection, все хорошо.
Теперь работаю над разгрузкой процессора,
дело в том что "сервера" юзают окна,
.. на 1 сетевое подключение 1 окно, кпримеру, если взять подключениме к HTTP серверу,
в доли секунды браузер открывает множество подключений.
Прикинул, что если обойдусь без окон (поток без окна), то возможно снизится нагрузка (неуверен, эксперементирую).
Обмен через SetEvent, но SetEvent непередает параметры.
с Publisher - Subscriber несталкивался, нада поглядеть

vd-vuf писал(а): собственно этот обмен нужен внутри приложения. PostMessage заюзал, сильно выручило.
обимен проходит на ура, избавился от ICriticalSection, все хорошо.

А почему не понравились критические секции и на какой версии клаши программу пишешь?
Кстатити, на этом сайте была статья из ClaMag о критических секциях.
http://www.clarionlife.net/content/view/65/29/
С уважением,
Bruce.

Bristan писал(а):

vd-vuf писал(а): собственно этот обмен нужен внутри приложения. PostMessage заюзал, сильно выручило.
обимен проходит на ура, избавился от ICriticalSection, все хорошо.

А почему не понравились критические секции и на какой версии клаши программу пишешь?
Кстатити, на этом сайте была статья из ClaMag о критических секциях.
http://www.clarionlife.net/content/view/65/29/
С уважением,
Bruce.

c6.3 9059, (по теме многопроцессорности опускался и на предыдущие билды)
пришел к выводу что CriticalSection выручает но не всегда (возможно и ошибочный вывод),
мой взгляд на это:
когда много потоков интенсивно юзают общие данные, динамческие очереди и пр, плюс к этому,
пинки на юзание прилетают и из API то вылет приложения, можно сказать, гарантирован, насмотря на CriticalSection.
Полагаю, что это видимо нормально, переключение процессоров на потоки может призойти
в любой момент (если на это смотреть через ассемблерный код, в подробности не вдавался).
Ну и плюс к этому, CriticalSection - педаль тормоза, то есть тормозим до тех пор пока не получим доступ.
А с PostMessage получилось все просто, для того чтобы передать данные в другой поток
создаем переменную и посылаем адресс этой перемнной в другой поток. (далее можем спать, прогуливатся или быстренько выполнять другой пинок)
Другой поток принимает адресс, по окончанию обработки уничтожает переменную. Все.. никто ни кого не ждет,
и ни кто не натыкается на данные которых уже нет.. какбы саморегулируящаяся синхронизация.
Хотя конечно, есть ситуации когда так просто не решить обмен, юзаем CriticalSection.