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