Ответ 1
Я бы обобщил, что писать высоко оптимизированный многопоточный процесс намного сложнее, чем просто бросать некоторые потоки в микс.
Я рекомендую начать со следующих шагов:
- Разделите свои рабочие нагрузки на отдельные параллельные исполняемые модули.
- Измерение и характеризация типов рабочей нагрузки - интенсивность сети, интенсивность ввода-вывода, интенсивность процессора и т.д. - они становятся основой для стратегий объединения ваших работников. например у вас могут быть довольно большие пулы работников для сетевых приложений, но нет смысла иметь больше рабочих, чем аппаратные потоки для задач с интенсивным процессором.
- Подумайте о очередности/массиве или ThreadWorkerPool для управления пулами потоков. Прежнее более мелкое зерно контролируется, чем последнее.
- Научитесь предпочитать шаблоны асинхронного ввода-вывода по шаблонам синхронизации, если можете - освобождает больше времени процессора для выполнения других задач.
- Работа по устранению или по меньшей мере сокращению сериализации вокруг конкурирующих ресурсов, таких как диск.
- Свести к минимуму ввод-вывод, получить и удерживать минимальный уровень блокировок на минимальный период. (Блокировка Reader/Writer - ваш друг)
5. Скомбинируйте этот код, чтобы гарантировать, что ресурсы заблокированы в последовательной последовательности, чтобы свести к минимуму смертельные объятия. - Тест как сумасшедшие условия гонки и ошибки в многопоточных приложениях адские для устранения неполадок - часто вы видите только криминалистические последствия массового убийства.
Имейте в виду, что вполне возможно, что многопоточная версия может работать хуже, чем однопоточная версия того же приложения. Нет никакого оправдания хорошим техническим измерениям.