Много потоков или как можно меньше потоков?
Для начала
https://jsfiddle.net/mplungjan/b2cagn8h/
....
history = el("#history"), // history
....
var historyString = oldNum + " " + operator + " " + theNum + " = " + resultNum;
if (historyString.indexOf("NaN") ===-1 && historyString.indexOf("undefined") === -1) {
history.innerHTML += historyString + "
";
}
Затем вы можете посмотреть в sessionStorage
5 ответов
Я пишу в.NET, и я не уверен, происходит ли способ, которым я кодирую, из-за ограничений.NET и их дизайна API или если это - стандартный способ сделать вещи, но это - то, как я сделал такого рода вещь в прошлом:
Объект очереди, который будет использоваться для обработки входящих данных. Это должно быть синхронизацией, заблокированной между потоком организации очередей и рабочим потоком для предотвращения условий состязания.
Рабочий поток для обработки данных в очереди. Поток, который стоит в очереди очередь данных, использует семафор для уведомления этого потока для обработки объектов в очереди. Этот поток будет запускать себя перед любым из других потоков и содержать непрерывный цикл, который может работать, пока он не получает запрос закрытия. Первая инструкция в цикле является флагом для приостанавливания/продолжения/завершения обработки. Флаг будет первоначально установлен приостановиться так, чтобы поток находился в состоянии ожидания (вместо цикличного выполнения непрерывно), в то время как нет никакой обработки, которая будет сделана. Поток организации очередей изменит флаг, когда будут объекты в очереди, чтобы быть обработанными. Этот поток затем обработает единственный объект в очереди на каждом повторении цикла. Когда очередь будет пуста, она задержит флаг для приостановки так, чтобы на следующем повторении цикла она ожидала, пока процесс организации очередей не уведомляет ее, что существует больше работы, которая будет сделана.
Один поток слушателя соединения, который прислушивается к запросам входящего соединения и выдает их к...
Поток обработки соединения, который создает соединение/сессию. Наличие отдельного потока от Вашего потока слушателя соединения означает сокращение потенциала для опоздавших на пересадку запросов из-за уменьшенных ресурсов, в то время как тот поток обрабатывает запросы.
Входящий поток слушателя данных, который прислушивается к входящим данным по текущему соединению. Все данные выданы к потоку организации очередей, который будет стояться в очереди для обработки. Ваши потоки слушателя должны сделать как можно меньше за пределами основного слушания и исчезновения данные для обработки.
Поток организации очередей, который стоит в очереди данные в правильном порядке, таким образом, все может быть обработано правильно, этот поток, повышает семафор до очереди обработки для уведомления его существуют данные, которые будут обработаны. Наличие этого потока, отдельного от входящего слушателя данных, означает, что Вы, менее вероятно, пропустите входящие данные.
Некоторый объект сессии, который передается между методами так, чтобы сессия каждого пользователя была сам содержавшая всюду по модели потоков.
Это подавляет потоки к столь же простому, но столь же устойчивая модель, как я выяснил. Я хотел бы найти более простую модель, чем это, но я нашел что, если я пытаюсь уменьшить модель потоков дальше, что я запускаю недостающие данные по сетевому потоку или опаздываю на пересадку запросы.
Это также помогает с TDD (Разработка через тестирование), таким образом, что каждый поток обрабатывает единственную задачу и намного легче кодировать тесты для. Наличие сотен потоков может быстро стать кошмаром распределения ресурсов, в то время как наличие единственного потока становится кошмаром обслуживания.
Намного более просто сохранить один поток на логическую задачу тем же путем, у Вас был бы один метод на задачу в среде TDD, и можно логически разделить то, что каждый должен делать. Легче определить потенциальные проблемы и намного легче зафиксировать их.
используйте поток событий / очередь и пул потоков для сохранения равновесия; это адаптируется лучше к другим машинам, которые могут иметь более или менее ядра
в целом намного более активные потоки, чем Вы имеют ядра, будет напрасно тратить время контекстное переключение
если Ваша игра будет состоять из большого количества коротких действий, то очередь событий проспекта/переработки даст лучшую производительность, чем постоянное число потоков
Для ответа на вопрос просто совершенно неправильно использовать 200 потоков на сегодняшних аппаратных средствах.
Каждый поток поднимает 1 МБ памяти, таким образом, Вы поднимаете 200 МБ файла подкачки, прежде чем Вы даже начнете делать что-либо полезное.
Любой ценой разбейте свои операции на маленькие кусочки, которые могут быть безопасно выполнены на любом потоке, но помещают те операции на очереди и имеют фиксированное, ограниченное количество рабочих потоков, обслуживающих те очереди.
Обновление: трата 200 МБ имеет значение? На 32-разрядной машине это - 10% всего теоретического адресного пространства для процесса - никакие дальнейшие вопросы. На 64-разрядной машине это походит на понижение океана того, что могло быть теоретически доступным, но на практике это - все еще очень большой блок (или скорее большое количество довольно больших блоков) устройства хранения данных, бессмысленно зарезервированного приложением, и которым затем должна управлять ОС. Это имеет эффект окружения ценной информации каждого клиента с большим бесполезным дополнением, которое уничтожает местность, побеждая ОС и попытки ЦП сохранить материал, к которому часто получают доступ, в самых быстрых слоях кэша.
В любом случае потери памяти являются всего одной частью безумия. Если у Вас нет 200 ядер (и ОС, способная к использованию) затем, у Вас действительно нет 200 параллельных потоков. Вы имеете (говорят) что 8 ядер, каждый отчаянно переключающийся между 25 потоками. Наивно Вы могли бы думать, что в результате этого, каждый поток испытывает эквивалент работы ядра, которое в 25 раз медленнее. Но это на самом деле намного хуже, чем это - ОС проводит больше времени, беря один поток от ядра и помещая другой на него ("контекстное переключение"), чем это делает на самом деле разрешение Вашего кода работать.
Только посмотрите, как любой известный успешный дизайн занимается этим видом проблемы. Пул потоков CLR (даже если Вы не используете его) служит прекрасным примером. Это начинается, предполагая всего, что один поток на ядро будет достаточен. Это позволяет больше быть созданным, но только гарантировать, что плохо разработанные параллельные алгоритмы в конечном счете завершатся. Это отказывается создавать больше чем 2 потока в секунду, таким образом, это эффективно наказывает жадные потоком алгоритмы путем замедления их.
Какова Ваша платформа? Если Windows затем, я предложил бы смотреть на асинхронные операции и пулы потоков (или Порты Завершения ввода-вывода непосредственно, если Вы работаете на уровне API Win32 в C/C++).
Идея состоит в том, что у Вас есть небольшое количество потоков, которые имеют дело с Вашим вводом-выводом, и это делает Вашу систему способной к масштабированию к большим количествам параллельных соединений, потому что нет никаких отношений между количеством соединений и количеством потоков, используемых процессом, который обслуживает их. Как ожидалось .NET изолирует Вас от деталей, и Win32 не делает.
Проблема использования асинхронного ввода-вывода и этого стиля сервера состоит в том, что обработка клиентских запросов становится конечным автоматом на сервере и данных, прибывающих триггерные изменения состояния. Иногда это берет некоторых привыкающих к, но после того как Вы делаете это действительно довольно изумительно;)
У меня есть некоторый бесплатный код, который демонстрирует различные проекты сервера в C++ с помощью IOCP здесь.
Если Вы используете Unix или должны быть кросс-платформенными, и Вы находитесь в C++ затем, Вы могли бы хотеть посмотреть на повышение ASIO, который обеспечивает асинхронную функциональность ввода-вывода.
Я думаю вопрос, который необходимо задавать, не то, если 200, поскольку общее количество потока является большим или плохим, а скорее сколько из тех потоков будет активным.
Если только несколько из них активны в какой-либо данный момент, в то время как все другие спят или ожидают или этажерка, то Вы в порядке. Потоки сна, в этом контексте, ничего не стоят Вам.
Однако, если все те 200 потоков активны, Вы собираетесь иметь свой ЦП, тратя впустую так много времени, делая контекстные переключения потока между всеми теми ~200 потоками.