Нужна консультация и опыт старших. Не откажите пожалуйста.

Задача такая: мультисерверный клиент для клиент-серверного приложения (один клиент для всех серверов).
протокол "общения" на основе xml.

Перечитал много документации, но все еще остались не ясными некоторые вопросы:

Вопрос 1. Потоки.
на данном этапе использую класс TThread для каждого сервера, но хочу перейти к потокам средствами WinAPI.

Создание потока:


Процедура потока:


И некая процедура SomeActions:


Вопрос звучит так: если процедура SomeActions будет одновременно запущена из обработчиков ProcessThread двух разных потоков без использования какиз либо методов синхронизации, предпринятых мной... что это получится? будет ли один поток ждать, пока другой поток отработает в этой функции?

Просто в случае с TThread все просто - там эту функцию можно было бы описать внутри класса и вызывать из обработчика Executeю В итоге разные потоки в разных экземплярах класса используют разные функции, а как быть в данном случае?


Вопрос 2. Сокеты.
На данном этапе у меня каждый поток самостоятельно, средствами WinAPI открывает сокет к собственному серверу, коннектится к нему, переводит сокет в неблокирующий режим и в бесконечном цикле в обработчике потока пытается читать с него данные, если они там есть, по необходимости отправлять запросы и т.д.

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

Вопрос: будет ли правильным такой подход? Если нет, то подскажите, в какую сторону рыть, посоветуйте более оптимальный вариант.

Вопрос 3. Парсер XML.
Сейчас использую TNativeXML. В общем очень хорош и удобен, но смущает то, что при одновременном парсинге 10 XML-пакетов (в 10 потоках) размером до 26 килобайт каждый, загрузка процессора упирается в 100% на 1-3 секунды.
Страшно представить что будет на 100 потоках - 100% на 30 секунд?

Посоветуйте пожалуйста, если есть на примете, более экономный, быстрый XML-парсер.
Требуется от него не так много:
- хватать XML для разбора из строки, а не только из файла.
- уметь проверь наличие того или иного тега
- работать со списками а-ля 



Пока все.
Заранее большое спасибо.

Нет смысла. Лучше оставить на Tthread. Хотя - Ваше право.

не будет. Если SomeActions "не лезет" за свои пределы, то никто никого ждать не будет (тут все будет зависеть от планировщика потоков Windows), но в то же время - проблем не возникнет.

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


Все зависит от количества планируемых подключений. Если их не сотни/тысячи, то такой подход имеет место быть, и даже более чем.
В противном случае - это будет засорение системы ненужным хламом в виде кучи потоков, которые винде нужно обработать, своевременно переключать и т.п. При большом количестве потоков - системе придется тяжко...
Вообще, раньше я пользовался именно этим методом. И считал его единственно верным и правильным (никому не навязываю свое мнение). Теперь же перешел к другой концепции (опять-таки, как вариант, но на текущий момент она меня более чем устраивает):
1 поток задействуется на обработку всех сетевых соединений (чтение/запись, создание/удаление). Ввиду того, что для современных процессоров сетевой обмен является достаточно медленным мероприятием (не беря в расчет 127.0.0.1), одного потока вполне хватает на весьма большую кучу соединений.
2 поток (а вот тут уже зависит от задачи, их может быть несколько) занимается обработкой данных, полученных/передаваемых из/в потока №1. Приводит их к удобоваримому виду и т.п.
3 поток (обычно - основной, т.е. vcl) занимается отображением информации, обработанной потоком №2 и взаимодействием с пользователем.

kami, спасибо за ответ.

Правильно ли я понял:

Поток 1 занимается только и исключительно сокетами: соединение, обработка ошибок соединения, приемом и передачей данных.
Поток 2 занимается полностью всей обработкой принятой информации и формированием пакетов данных для отправки? т.е., по сути Поток 1 накидывает принятые пакеты в буфер Потока 2 для обработки, а Поток 2 накидывает в буфер потока 1 данные для отправки.

Верно?

И вдогонку: Как первый поток читает список сокетов? Это пребор в цикле всех сокетов, и они в неблокируемом режиме или-таки события?

Я бы еще попросил пример обработки нескольких сокетов в одном потоке, если можно...

Это сообщение отредактировал(а) knyshow - 6.5.2011, 14:30

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


Не совсем понял вопрос. А, Вы же пишете на WinAPI... тогда не знаю, чем помочь. Я использую TServer|TClientSocket, которые по сути - минимальная надстройка над API. Там с этим гораздо проще...открыл соединение в контексте дополнительного потока - следовательно все события будут вызываться в контексте этого потока, в результате список сокетов понадобится только для хранения объектов, чтобы своевременно их уничтожать. Но события этих компонентов вызываются при приеме сообщений Windows, посему, думаю, аналогию провести можно.


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

Это сообщение отредактировал(а) kami - 6.5.2011, 21:26

kami, заранее огромное спасибо. буду ждать.
не заморачивайтесь на протоколе. так или иначе, используете Вы бинарный протокол, XML или ini или... принцип получения и отправки пакетов одинаков