Здравствуйте, BloodyTux, Вы писали:
BT>Здравствуйте!
BT>Возникла следующая задача: имеется большое количество клиентских потоков (высокая конкуренция, т.е. порядка 100-200 штук ) и несколько рабочих в зависимости от числа ядер процессора. Клиенты отправляют задания для рабочих потоков (помещают в общую очередь), а потом через некоторое время проверяют выполнено ли задание и забирают результат, если он готов. Основное требование — постоянная загрузка рабочих потоков. Я прикинул, что если скажем 2 рабочих потока будут ломится через тот же мьютекс, что и 200 потоков клиентов, то они будут простаивать. Вопрос: спасут ли ситуацию lock-free алгоритмы? Или может быть есть какое-то типовое решение данной проблемы.
При таком количестве потоков вас уже ниче не спасет.
Здравствуйте, BloodyTux, Вы писали:
BT>Возникла следующая задача: имеется большое количество клиентских потоков (высокая конкуренция, т.е. порядка 100-200 штук ) и несколько рабочих в зависимости от числа ядер процессора. Клиенты отправляют задания для рабочих потоков (помещают в общую очередь), а потом через некоторое время проверяют выполнено ли задание и забирают результат, если он готов. Основное требование — постоянная загрузка рабочих потоков. Я прикинул, что если скажем 2 рабочих потока будут ломится через тот же мьютекс, что и 200 потоков клиентов, то они будут простаивать. Вопрос: спасут ли ситуацию lock-free алгоритмы? Или может быть есть какое-то типовое решение данной проблемы.
Судя по тому, что consumer-ов у вас много, порядок обработки заданий вам не очень важен. Поэтому в исползовании очереди нет необходимости. Только некоторые fairness guarantees. Поэтому используйте по одной очереди для каждого рабочего потока, добавляйте новую работу в случайно выбранную очередь, и в случае если очередь конкретного рабочего потока пуста, пусть этот поток берет работу из очереди другого потока.
Здравствуйте, BloodyTux, Вы писали:
BT>Ну насчет 200 я наверное погорячился — вообще система реализована в виде tcp-сервера с threadpool, т.е. грубо говоря потоков может быть и меньше, а вот одновременных запросов от клиентов 200 спокойно.
threadpool сам по себе содержит очередь задач, вот и используй его же для обработки
Здравствуйте, BloodyTux, Вы писали:
BT>Здравствуйте!
BT>Возникла следующая задача: имеется большое количество клиентских потоков (высокая конкуренция, т.е. порядка 100-200 штук ) и несколько рабочих в зависимости от числа ядер процессора. Клиенты отправляют задания для рабочих потоков (помещают в общую очередь), а потом через некоторое время проверяют выполнено ли задание и забирают результат, если он готов. Основное требование — постоянная загрузка рабочих потоков. Я прикинул, что если скажем 2 рабочих потока будут ломится через тот же мьютекс, что и 200 потоков клиентов, то они будут простаивать. Вопрос: спасут ли ситуацию lock-free алгоритмы? Или может быть есть какое-то типовое решение данной
проблемы.
Зачем держать очередь и шедулить работу потоков самому когда для этого придуман пул потоков, который как раз и заботится что бы максимально эффективно нагрузить CPU, и следит за количеством потоков и распределяет им задачи из очереди.
Возникла следующая задача: имеется большое количество клиентских потоков (высокая конкуренция, т.е. порядка 100-200 штук ) и несколько рабочих в зависимости от числа ядер процессора. Клиенты отправляют задания для рабочих потоков (помещают в общую очередь), а потом через некоторое время проверяют выполнено ли задание и забирают результат, если он готов. Основное требование — постоянная загрузка рабочих потоков. Я прикинул, что если скажем 2 рабочих потока будут ломится через тот же мьютекс, что и 200 потоков клиентов, то они будут простаивать. Вопрос: спасут ли ситуацию lock-free алгоритмы? Или может быть есть какое-то типовое решение данной проблемы.
Здравствуйте, BloodyTux, Вы писали:
BT>Возникла следующая задача: имеется большое количество клиентских потоков (высокая конкуренция, т.е. порядка 100-200 штук ) и несколько рабочих в зависимости от числа ядер процессора. Клиенты отправляют задания для рабочих потоков (помещают в общую очередь), а потом через некоторое время проверяют выполнено ли задание и забирают результат, если он готов. Основное требование — постоянная загрузка рабочих потоков. Я прикинул, что если скажем 2 рабочих потока будут ломится через тот же мьютекс, что и 200 потоков клиентов, то они будут простаивать. Вопрос: спасут ли ситуацию lock-free алгоритмы? Или может быть есть какое-то типовое решение данной проблемы.
С разных концов очередь могут охранять разные мьютексы.
Здравствуйте, Gurney, Вы писали:
G>Судя по тому, что consumer-ов у вас много, порядок обработки заданий вам не очень важен. Поэтому в исползовании очереди нет необходимости. Только некоторые fairness guarantees. Поэтому используйте по одной очереди для каждого рабочего потока, добавляйте новую работу в случайно выбранную очередь, и в случае если очередь конкретного рабочего потока пуста, пусть этот поток берет работу из очереди другого потока.
G>Такие схемы как правило есть уже готовые.
G>А вам действительно нужно 200 клиентских потоков?
Да, верно, порядок не столь важен. С разделением задач по рабочим потокам понятно, а вот как сделать, чтобы они имели постоянную загрузку?
SergH,
Можно подробнее про два мьютекса на одну очередь, есть ли готовые решения для с++?
Ну насчет 200 я наверное погорячился — вообще система реализована в виде tcp-сервера с threadpool, т.е. грубо говоря потоков может быть и меньше, а вот одновременных запросов от клиентов 200 спокойно.
Здравствуйте, BloodyTux, Вы писали:
BT>Здравствуйте, Gurney, Вы писали:
G>>Судя по тому, что consumer-ов у вас много, порядок обработки заданий вам не очень важен. Поэтому в исползовании очереди нет необходимости. Только некоторые fairness guarantees. Поэтому используйте по одной очереди для каждого рабочего потока, добавляйте новую работу в случайно выбранную очередь, и в случае если очередь конкретного рабочего потока пуста, пусть этот поток берет работу из очереди другого потока.
BT>Да, верно, порядок не столь важен. С разделением задач по рабочим потокам понятно, а вот как сделать, чтобы они имели постоянную загрузку?
А что вы подразумеваете под постоянной нагрузкой? Равное разделение нагрузки между потоками?
Здравствуйте, BloodyTux, Вы писали:
BT>Здравствуйте!
BT>Возникла следующая задача: имеется большое количество клиентских потоков (высокая конкуренция, т.е. порядка 100-200 штук ) и несколько рабочих в зависимости от числа ядер процессора. Клиенты отправляют задания для рабочих потоков (помещают в общую очередь), а потом через некоторое время проверяют выполнено ли задание и забирают результат, если он готов. Основное требование — постоянная загрузка рабочих потоков. Я прикинул, что если скажем 2 рабочих потока будут ломится через тот же мьютекс, что и 200 потоков клиентов, то они будут простаивать. Вопрос: спасут ли ситуацию lock-free алгоритмы? Или может быть есть какое-то типовое решение данной проблемы.
Ну насчет 200 я наверное погорячился — вообще система реализована в виде tcp-сервера с threadpool, т.е. грубо говоря потоков может быть и меньше, а вот одновременных запросов от клиентов 200 спокойно.
Здравствуйте, ilnar, Вы писали:
I>можете еще посмотреть Intel TBB, там есть конкуррентные очереди, а еще модель задач (task) с автоматическим выбором числа потоков на основе числа ядер
Здравствуйте, remark, Вы писали:
R>Здравствуйте, gandjustas, Вы писали:
G>>При таком количестве потоков вас уже ниче не спасет.
R>При таком — каком? Большом? Пора бы уже войти в эпоху многоядерных процессоров
R>
Даже 200 потоков, это сильно больше среднего числа процессоров. Затраты на переключение все еще ненулевые.
Здравствуйте, gandjustas, Вы писали:
R>>При таком — каком? Большом? Пора бы уже войти в эпоху многоядерных процессоров
G>Даже 200 потоков, это сильно больше среднего числа процессоров. Затраты на переключение все еще ненулевые.
Современные ОС вполне способны держать по 10 логических потоков на 1 физический поток без видимых издержек. Итого получаем, если у нас 4 12-ти ядерных процессора, примерно 500 потоков будет работать без проблем.
Частота переключения потоков не зависит от их количества. Если у тебя в 10 раз больше потоков, это не значит, что ОС будет их переключать в 10 раз чаще. Частота переключения скорее постоянная.
