Здравствуйте, minorlogic, Вы писали:
M>Очевидно что для эфективности такой объект должен жить в одном экземпляре. Остальное ты сам додумал.
Гм. А можно развернуть это "очевидное" доказательство?
У меня лично ровно обратное ощущение: одним пулом потоков можно пользоваться ровно до тех пор, пока недостаточная эффективность не приведет к необходимости использовать больше.
Подробнее:
основным параметром пула потоков является предел количества одновременно выданных потоков. Если его необоснованно завышать, то throughput будет снижаться из-за расходов на переключение контекста. Грубо говоря, выдавать "еще один" поток из пула можно тогда, когда часть CPU ресурсов простаивает. В противном случае, лучше подождать освобождения занятого потока. К сожалению, известные мне реализации не способны достаточно эффективно отслеживать реальную нагрузку, поэтому пулы реализованы в предположении однотипности потоков, а также в предположении, что администратор в состоянии сам оценить разумное количество потоков для одновременного исполнения.
Как только предположение об одинаковости потоков нарушается, начинаются проблемы. Пример: веб приложение, в котором одна страница генерится быстро, а другая обращается к удаленному серверу. Обращения к странице №1 обрабатываются нашим CPU. В среднем, поток, обрабатывающий запрос к странице №1, занимает 25% CPU. Это означает, что не имеет смысла разрешать запускать более четырех потоков одновременно.
Поток, обрабатывающий страницу №2, большую часть времени спит. В
среднем, он занимает 1% СPU. Это означает, что лимит в 4 потока загрузит нашу машину примерно на 4%, остальные запросы будут ждать в очереди. Очевидно, что throughput будет примерно в 25 раз ниже, чем мог бы быть. Лимит в 100 потоков приведет к тому, что одновременно будут обслуживаться слишком много запросов к странице 1, увеличивая response time и опять же снижая throughput.
В результате, очевидно, что для достижения максимальной эффективности в данном случае придется завести
два пула потоков, с совершенно различными лимитами. Что, кстати, описано в соответствующей статье от Microsoft.
В связи с вышеизложенным, мне никак не понятно, каким боком требования эффективности могут привести к предложенному тобой ограничению на количество пулов потоков.
З.Ы. В качестве оффтопа, можно пообсуждать возможные реализации пулов ресурсов, способные избегать описанной проблемы даже при единственном экземпляре пула в системе.
... << RSDN@Home 1.2.0 alpha rev. 677>>