Дизайн критической секции IOCP

Question

Я запускаю полностью действующее приложение сокета IOCP TCP. Сегодня я думал о проекте Critical Section, и теперь у меня есть один бесконечный вопрос в моей голове: глобальный или критический раздел для каждого клиента? Я пришел к этому, потому что, как я вижу, нет смысла использовать несколько рабочих потоков, если каждый поток зависит от одного замка, не так ли? Я имею в виду ... теперь я не вижу проблемы с производительностью с 100 одновременными клиентами, но что, если было 10000?

Мой общий ресурс предназначен для каждой предварительно распределенной структуры, поэтому каждый клиент имеет свой собственный контекст ввода-вывода, сокет и прочее. Не существует доли ресурсов между клиентами, поэтому я думаю, что это еще один момент для использования на клиентской CS. Я использую один поток accept и 8 (процессоры * 2) рабочих потоков. Эти приложения в основном разработаны для небольших (< 1KB) пакетов, но иногда для потоковой передачи файлов.

Answer 1

«Правильный» ответ, вероятно, зависит от вашего дизайна, количества одновременных клиентов и производительности, требуемой от имеющегося у вас оборудования.

В целом, я считаю, что лучше всего пойти с простейшей вещью, которая работает, а затем профилем, чтобы найти горячие точки.

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

Так как это за соединение, то очевидный (для меня) дизайн будет состоять из состояния каждого соединения с его собственным критическим разделом. Что вы считаете недостатком этого подхода?

Проблема с единой общей блокировкой заключается в том, что вы вводите конкуренцию между соединениями (и потоками), которые не имеют причин блокировать друг друга. Это негативно скажется на производительности и, скорее всего, станет горячей точкой по мере роста числа подключений.

Как только у вас есть блокировка соединения, вы можете захотеть избежать использования его как можно чаще, если потоки IOCP просто блокируются, чтобы поместить завершение в очередь на соединение для обработки. Это имеет то преимущество, что один нить IOCP может работать на каждом соединении и препятствовать тому, чтобы одно соединение блокировало дополнительные блоки IOCP. Он также хорошо работает с обработкой «пропуск пропускной способности при успешном завершении».