Потоки, потоки и еще раз потоки

← →
Кодер (2003-07-27 21:46) [0]

Доброго времени суток. Не подскажете как правильно и грамотно обрабатывать потоки ( Thread) при использовании компонента TServerSocket. Как их (потоки, процессы) создавать при подключении клиента к серверу, как их отслеживать (в случае, когда необходимо получить данные)? А как необходимо поступать в случае, если несколько потоков сразу прислали пакеты? Как их (потоки) одновременно обработать? Используется ли при этом единый буфер или нет? И вообще stThreadBlocking единственный ли удобный асинхронный тип работы сокета?

← →
Digitman (2003-07-28 09:08) [1]

> как правильно и грамотно обрабатывать потоки (Thread) при
> использовании компонента TServerSocket

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

> Как их (потоки, процессы) создавать при подключении клиента
> к серверу, как их отслеживать (в случае, когда необходимо
> получить данные)?

процессы не нужно создавать, этим занимается ОС.

декларируй и реализуй класс-наследник TMyTransportThread = class(TServerClientThread).
в его override-методе ClientExecute организуй обычную работу с объектом ClientSocket: TServerClientWinSocket (практически ничем не отличающуюся от работы с ним же в осн.код.потоке)
при коннекте клиента сервер при необходимости (если в кэше нет свободных код.потоков) возбудит событие OnGetThread(), в обработчике которого создай экземпляр TMyTransportThread и верни ссылку на него в 3-м параметре SocketThread. Сервер автоматически назначит св-ву MyTransportThread.ClientSocket значение, равное ссылке на объект TServerClientWinSocket, который будет представлять данного клиента на серверной стороне и обращение к методам св-вам которого в теле ClientExecute будет реализовывать транспорт данных для этого клиента.

> А как необходимо поступать в случае, если
> несколько потоков сразу прислали пакеты? Как их ...одновременно обработать ?

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

> Используется ли при этом единый буфер

на уровне приложения - не используется

> stThreadBlocking единственный ли удобный асинхронный тип
> работы сокета

по умолчанию он вообще синхронный.
асинхр.режим - это stNonBlocking

"удобства" зависят от постановки конечной задачи

← →
Кодер (2003-07-28 13:03) [2]

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

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

← →
Digitman (2003-07-28 13:35) [3]

> А в чем принципиальная разница между этими асинхр. режимами
> stNonBlocking и stThreadBlocking (по скорости обработки
> приложением, какой из способов больше нагружает систему)?

еще раз повторяю

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

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

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

> по скорости обработки приложением

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

какой из способов больше нагружает систему

разумеется - stThreadBlocking, ибо каждый код.поток, создаваемый в этом режиме, занимает опред.сист.ресурсы

> если нужно одновременно обрабатывать множество входящих
> потоков и при этом выполнять какие-либо действия, совершенно
> не отсящиеся к сокетам и передачи данных по сети

как раз для этой цели и предназначен режим stThreadBlocking

> Как в этом случае организовывается правильная, "параллельная"
> работа внутри приложения?

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

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

> как реализовывается совместная работа (взаимодействие) "основного"
> потока и "сокетных" потоков?

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

трансп. же код.потоки как раз и создаются для того, чтобы решать специф.задачу - прием/передачу (возможно, и обработку) данных, которые циркулируют по вирт.петле соединения с тем клиентом, ClientSocket-гнездо которого создано объектом TServerSocket и ассоциировано с одним из трансп.код.потоков

← →
Кодер (2003-07-28 15:35) [4]

Спасибо!

Потоки, потоки и еще раз потоки Найти похожие ветки