Unithreaded design или многопоточный дизайн?
Итак, вот мой сценарий:
Я читаю из сокета и, основываясь на содержимом пакета, помещаю пакет в соответствующую очередь. Поэтому, если у меня есть 10 очередей, будет 10 if-else -ifs или 10 случаев оператора switch для выбора правильной очереди. Таким образом, может быть не более 10 сравнений.
Другим способом может быть попросить вещатель / сервер вещать на 10 разных портах, где канал от каждого порта будет иметь пакеты для одной конкретной очереди, на моем конце я могу прослушивать каждый сокет через отдельный поток (или я могу использовать поток пул, если трафик на определенных портах меньше / неравномерен). Так что теперь мне не нужно выбирать, к какой очереди принадлежит пакет, но теперь введено явление переключения контекста.
Отсюда мой интеллект и технические знания мешают мне идти дальше.
Любая поддержка, какой подход будет работать лучше?
Решение
Это личный выбор. Если трафик адекватный или меньше, чем очевидно, первый подход лучше. Это потокобезопасно, благодаря нить лишение свободы. Проще поддерживать. Единственная проблема заключается в том, что — если добавлен дополнительный порт, вам придется изменить код для дополнительного предложения if.
Но в условиях интенсивного движения это может быть лучше. Меньшие пакеты будут потеряны, если буфер заполнен. Может работать лучше в зависимости от количества ядер, но опять-таки может содержать ошибки, если не выполняется должным образом.
Если бы я был тобой, я бы пошел вперед с первым. Будь проще.
Другие решения
Если вы используете Windows, проверьте порты завершения ввода-вывода (IOCP), если Linux попробует epoll. Они, как правило, являются наиболее эффективными моделями в обеих системах соответственно (в общем случае). Модель Windows IOCP может быть красиво привязана к пулу потоков с помощью ОС.