ТАкая ситуация. Клиент логинится на сервер и просит его выслать ему информацию. На каждый запрос создается поток. Соединение довольно скоротечное и сокеты блокирующие. Сейчас код выглядит так.
void Server::OnRead ()
{
if (command == "get")
{
Data* data = new Data;
data->id = ...
data->data = ...
AfxBeginThread (Thread, (LPVOID) data, ...)
}
}
Вообщем для каждого треда создается структура как параметр. Подскажите, можно ли как нибудь иметь пул потоков для этого дела и при получении очередного запроса передавать данные уже в имеющийся поток? Все таки создавать поток для каждого соединений как то по жлобски.
Покажите пожалуйста немного кода.
спасибо
04.11.05 22:04: Перенесено модератором из 'C/C++' — Павел Кузнецов
Здравствуйте, <Аноним>, Вы писали:
А>ТАкая ситуация. Клиент логинится на сервер и просит его выслать ему информацию. На каждый запрос создается поток. Соединение довольно скоротечное и сокеты блокирующие. Сейчас код выглядит так.
А>Вообщем для каждого треда создается структура как параметр. Подскажите, можно ли как нибудь иметь пул потоков для этого дела и при получении очередного запроса передавать данные уже в имеющийся поток? Все таки создавать поток для каждого соединений как то по жлобски.
Здравствуйте, Аноним, Вы писали:
А>ТАкая ситуация. Клиент логинится на сервер и просит его выслать ему информацию. На каждый запрос создается поток. Соединение довольно скоротечное и сокеты блокирующие. Сейчас код выглядит так.
А>Вообщем для каждого треда создается структура как параметр. Подскажите, можно ли как нибудь иметь пул потоков для этого дела и при получении очередного запроса передавать данные уже в имеющийся поток? Все таки создавать поток для каждого соединений как то по жлобски.
А>Покажите пожалуйста немного кода.
А>спасибо
А>Вообщем для каждого треда создается структура как параметр. Подскажите, можно ли как нибудь иметь пул потоков для этого дела и при получении очередного запроса передавать данные уже в имеющийся поток? Все таки создавать поток для каждого соединений как то по жлобски.
уже подсказали, см. выше. Хочу добавить, так как соединение довольно скоротечное, будет удобно складывать запросы в очередь и в отдельном потоке вычитывать запрос, ждать освободившийся/незанятый поток из пула и им обрабатывать запрос.
по реализации конкретно:
— ATL::CThreadPool,
— std::queue<boost::shared_ptr<Data> >
Здравствуйте, Аноним, Вы писали:
А>то есть насколько я понял все что мне надо это просто заменить AfxBeginThread () на QueueUserWorkItem () ?
я первый раз этот метод вижу
но судя по описанию это почти то что тебе нужно, почему почти? потому как все скорее всего прийдется складывать запросы в свою очередь.
Re[4]: Пул потоков
От:
Аноним
Дата:
04.11.05 15:24
Оценка:
Здравствуйте, Angler, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>то есть насколько я понял все что мне надо это просто заменить AfxBeginThread () на QueueUserWorkItem () ?
A>я первый раз этот метод вижу A>но судя по описанию это почти то что тебе нужно, почему почти? потому как все скорее всего прийдется складывать запросы в свою очередь.
Да судя по всему новая функция, для нее качаю последний SDK Что значит складывать запросы в очередь? Разве система сама не распределит какой поток из системного пула будет выполнять тот или иной запрос?
Здравствуйте, Аноним, Вы писали:
А>Да судя по всему новая функция, для нее качаю последний SDK Что значит складывать запросы в очередь? Разве система сама не распределит какой поток из системного пула будет выполнять тот или иной запрос?
Ты ведь сам писал, что "Соединение довольно скоротечное". Представь себе ситуацию, когда в пуле нет свободного потока, а к серверу приходит запрос от клиента. В этои случае сервер сможет отдать управление клиенту только в случае появления свободного потока в пуле. Чтобы не ждать, можно организовать на сервере еще и очередь клиентских запросов:
Здравствуйте, Angler, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
A>Ты ведь сам писал, что "Соединение довольно скоротечное". Представь себе ситуацию, когда в пуле нет свободного потока, а к серверу приходит запрос от клиента. В этои случае сервер сможет отдать управление клиенту только в случае появления свободного потока в пуле. Чтобы не ждать, можно организовать на сервере еще и очередь клиентских запросов:
А сколько потоков может быть в пуле? ведь это так называемый системный пул так? им сама система управляет?
Use this macro when specifying the Flags parameter. The macro parameters are the desired flags and the new limit (up to (2<<16)-1 threads). However, note that your application can improve its performance by keeping the number of worker threads low.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
А>Вообщем для каждого треда создается структура как параметр. Подскажите, можно ли как нибудь иметь пул потоков для этого дела и при получении очередного запроса передавать данные уже в имеющийся поток? Все таки создавать поток для каждого соединений как то по жлобски.
А>Покажите пожалуйста немного кода.
А>спасибо
Здравствуйте, Аноним, Вы писали:
А>ТАкая ситуация. Клиент логинится на сервер и просит его выслать ему информацию. На каждый запрос создается поток. Соединение довольно скоротечное и сокеты блокирующие. Сейчас код выглядит так.
А>Вообщем для каждого треда создается структура как параметр. Подскажите, можно ли как нибудь иметь пул потоков для этого дела и при получении очередного запроса передавать данные уже в имеющийся поток? Все таки создавать поток для каждого соединений как то по жлобски.
А>Покажите пожалуйста немного кода.
А>спасибо
Здравствуйте, Аноним, Вы писали:
А>ТАкая ситуация. Клиент логинится на сервер и просит его выслать ему информацию. На каждый запрос создается поток. Соединение довольно скоротечное и сокеты блокирующие. Сейчас код выглядит так.
Дурная мысль: а зачем там потоки вообще?
Дело в том что сокеты сами по себе очереди (входящие) и если у тебя
отдаваемая информация под рукой проще отдать её сразу.
Очень большая вероятность что такое решение будет работаь быстрее
чем на потоках. UDP еще для такого типа трафика весьма полезно.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Аноним, Вы писали:
А>>ТАкая ситуация. Клиент логинится на сервер и просит его выслать ему информацию. На каждый запрос создается поток. Соединение довольно скоротечное и сокеты блокирующие. Сейчас код выглядит так.
CS>Дурная мысль: а зачем там потоки вообще?
CS>Дело в том что сокеты сами по себе очереди (входящие) и если у тебя CS>отдаваемая информация под рукой проще отдать её сразу.
CS>Очень большая вероятность что такое решение будет работаь быстрее CS>чем на потоках. UDP еще для такого типа трафика весьма полезно.
Полностью согласен с c-smile — в большинстве случаев потоки действительно не нужны. Но если уж совсем критично (скорость, надежность), то смотреть лучше не в сторону потоков и даже их пула (хотя всегда есть варианты) — а в сторону организации еще одной очереди, куда вы будете отправлять принятые вами сообщения — очереди на обработку сообщений (ка вариант см. MessageQueue, Service Broker на Yukon, AQ Oracle и даже Names Pipe) — просто на другой стороне очереди (возможно даже на другом железе) организуете нужное вам количество слушающих эту очередь потоков и все.