Критическая секция IOCP

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

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

2

Решение

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

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

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

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

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

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

3

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]