Многопоточность заданий, которые должны поддерживать порядок - PullRequest
0 голосов
/ 01 февраля 2011

У меня есть процесс ac / c ++, который имеет длинную очередь, и каждый элемент в этой очереди должен быть отправлен на несколько (TCP) серверов.Одиночный поток - это опция, которая работает, однако она медленная.

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

Одно важное замечание.Работа может быть зависимой.Я не хочу выполнять job_10, если job_5 не завершена. Заказ необходимо поддерживать.

Прежде всего, я хотел бы узнать ваше мнение по этому вопросу.Во-вторых, я ищу реализации C ++ для справки.В-третьих, я ищу книги / источники, которые описывают подобные проблемы.

Ответы [ 2 ]

3 голосов
/ 01 февраля 2011

Вы смотрели на boost asio?Он поддерживает концепцию «пула потоков», поэтому вместо одного потока на сервер (который является синхронным) можно создать пул потоков, обрабатывающих большое количество соединений асинхронно.Производительность тоже неплохая ...

0 голосов
/ 01 февраля 2011

Как вы пришли к выводу, что вам нужно многопоточное решение? Что вы имеете в виду, когда говорите, что ваше однопоточное решение «медленное»? Вы имеете в виду, что другая обработка (возможно, пользовательский интерфейс?) Задерживается, пока элементы отправляются на сервер? Или весь процесс занимает слишком много времени?

Ваше описание по этому вопросу неоднозначно: каждый элемент должен быть отправлен на все серверы или только на один? Похоже, только один, но я не уверен. Если оно должно быть отправлено всем, сложность многопоточного решения значительно возрастает.

Можете ли вы удалить элемент из очереди после его отправки или вам нужно дождаться подтверждения от сервера? Если вам придется подождать, тогда ваше управление очередью станет сложным - вы не можете удалить элемент, пока он не будет подтвержден, и поэтому вам придется пометить его как ожидающий, и поток, который выбирает следующий элемент из очереди, будет нуждаться чтобы быть уверенным, что он не выберет ожидающий предмет. И когда элемент был успешно отправлен, его придется удалить из очереди, что подразумевает одновременный доступ на запись в очередь.

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

Вы говорите, что ваш процесс не знает заранее, сколько существует серверов. Может ли этот номер измениться во время обработки?

Обязательно изучите многопоточность, но вы можете обнаружить, что ваше «медленное» однопоточное решение наилучшим образом отвечает потребностям вашего бизнеса - легко внедряется и надежно. Если нет, то, надеюсь, некоторые из этих вопросов будут вам полезны.

...