Это когда куча сокетов в массиве а потом в цикле WaitForMultipleObjects()? Старо как мир же )

Ну товарищ не уточнил мы хотим обслужить 10000 коннектов в секунду с отдачей каждому по 2 байта или подключаем 900 клиентов и каждый просит у сервера что хочет. В том числе и нечто, что заставляет сервер подождать(прихода некоего события или интенсивные вычисления потребуются).

ну а смысл что-то тестировать если и так ясно, что вы говорили про сценарий с 2мя байтами и большим коннект рэйтом, а я про обслуживание клиентов параллельно. Две разные задачи два разных решения. Доказывать Вам, что то-же самое решение будет потреблять еще меньше ресурсов если заменить JS на C у меня желания нет. Это уже совсем холливар какой-то получится.

Вы все равно ничего не поняли. Ключевое слово Wait - оно у вас в голове и у меня тоже было, и очень трудно его было оттуда выбросить.
WaitForMultipleObjects() заблокирует поток, а у нас нет блокировок, нет Wait, у нас есть On


Сервер будет отдавать запрошенный пользователем файл - устроит? Тестить будете?
В математику давайте пока лесть не будем, об этом позже и там тоже все довольно интересно и тоже все отлично ложится на SST-модель. Просто Javascript не предназначен для сложных вычислений, для этого есть другие инструменты, которые свободно работают в паре с JS.


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

Могу в аналогичном тоне заявить, что наверно вы тоже ничего не поняли и у вас в голове On. Чтобы кто-то вызвал этот On должен быть где-то и Wait и цикл бесконечный.
Например в эмбэддэд с этим проще, потому что этот вэйт реализуется логикой отвечающей за генерацию прерывания по изменению уровня пина(например). И вы потом гордо залетаете в прерывание, оттуда вызываете свой On и радуетесь. Но кто-то до этого аппаратно делал Wait )

Даже в SST таки есть бесконечный цикл, который крутится и вызывает нужные On взависимости от ивэнтов в очереди.
Чем это отличается от WaitForMultipleObjects() для сокетов? Я не знаю. Наверно ни чем)
Но делая этот системный вызов я отдаю ресурсы другим потокам в ОС(ох уж эти потоки опять а!). Хотя таки да, мог бы крутить цикл и проверять сокеты вручную, потом ложить ивэнт в очередь а потом вызывать On И как глубоко бы вы не зкапывали этот цикл или вэйт он всё равно где-то есть.

Если вы в JS подписываетесь на какое-то событие, чтобы движок дёргал ваш On - это всего-лишь означает что нужный Wait и цикл скрыты где-то далеко.
Так что не шибко то разгоняйтесь с перестраиванием мозга на On.

Надеюсь вы таки поняли о чем я говорю ) Потому что хоть вы в это и не верите, а большинство и с принципами работы SST тут разобрались и про On знают не по наслышке тоже давно )

Файл объемом 1Гб, скорость сети каждого клиента ограничиваем шейпером на роутере до....1мегабита ) Ну, чтоб точно заметно было как остальные клиенты сервера курят бамбук )
Не тратьте силы и так всё ясно же. Застрянет ваш сервер на одном клиенте и пока тот файл не скачает - всё это весело встанет колом.

Ааа, нет! Я придумал! В системе появится таймер, он будет генерировать событие onTimer, в этом событии вы будете проходиться по массиву с сокетами и каждому отправлять там по пару байт данных. Обходя сокеты по кругу. А потом скажите ну вот, все качают и никаких вэйтов ))))))))))

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

Это верно. Я выбросил из головы Wait и вдул туда On.


Нет, в этом нет необходимости. Хотя физически, как Вы подметили один такой цикл вполне может быть, это обусловлено самой архитектурой конкретного процессора. Но он пустой, кроме как инструкции sleep там больше ничего нет.



А тут Вы уже не правы. WaitForMultipleObjects блокирует пользовательский поток. Все, поток мертвый. В то время, как в SST или яваскрипте в принципе нет такой возможности


Ну пусть себе будет этот цикл где-то один единственный, зачем программисту о нем думать? Хотя физически его может и не быть или он будет абсолютно пустой, но дело не в этом.
Вы, например, когда пишете код на С думаете, какой при этом байт-код получается? Какие инструкции при этом генерит компилятор, какие регистры использует?



Для безопасности есть MPU/MMU, если оно действительно нужно - тогда запросто берем и используем.


Идет. Будете тестить? Файлик сами приготовите любой. Только боюсь, в этом случаи мы не SST-модель будем тестить, а Ваш жесткий диск или Ваш порезанный канал. Но как только Вы подсунете нормальный файл на несколько КБ-МБ и сделаете канал, достаточный для закрузки сервака на полную - все станет совсем иначе.
Хотя даже с гиговым файлом/файлами однопоточный javascript покажет выше производительность, чем классический многопоточный C. Проверим?

В случае единого стека всех потоков с трудом представляю его использование

Ну во-первых там есть таймаут. Так что поток не мёртвый ) А во-вторых если ему делать больше нечего, то и поспать не помешает. Хотел донести до вас наконец, что за вашими On по любому стоят и Waitы и ветвления. Но видимо мозг уже слишком перевдут ))))))

Кстати даже этот WaitForMultipleObjects() подразумевает, что мы делегируем эту задачу ядру и оно проверяет за нас и сокеты и таймаут. И если что разбудит.

Ваша задача в SST тоже отработала и типа спит, её запустят когда надо будет. Хороша аналогия? Потому что в пределах ОС мой поток(процесс) это и есть задача. Кто бы мог подумать, а ))))
Мой поток будет разбужен(запущен) когда в сокете появятся данные. Осталось назвать файл OnSocketReadyRead.exe и вы сразу поймете что к чему.

Вы не поверите, но в той или иной степени ДА. Каждый Си программист с опытом работы так или иначе об этом думает. Без этого никуда. Хотя чем дальше тем умнее становятся компиляторы и возможно когда-нибудь настанет тот день, когда это делать вообще будет не нужно. Но на наш век работы хватит.

Без конкретной задачи и не представите.

Зачем надо MPU? Мне, например, нужен только для того, чтобы отловить переполнение общего стека, поскольку на этапе компиляции этого сделать невозможно. А проверкой за выходы за границы массивов и других проблем с памятью занимается компилятор во время компиляции. Я вот все больше присматриваюсь к языку Rust, там компилятор еще более строгий и еще больше делает проверок на этапе компиляции, чем C++. Там ошибок с памятью быть практически не может, разве что если Вы сами этого захотите - засунете код в специально для этого предназначенный Unsafe-блок.

Зачем нужен MMU? Он нужен, чтобы пользователь вашей системы смог запускать свои приложения на ней, и при этом криво написанные приложения не завалили всю систему. В пределах одной программы он не нужен.

Огласите пожалуйста чётко и ясно что мы будем измерять и в каких условиях и конечно же проверим.

Ну, чтобы всё это было не просто бла бла бла, а конкретно. Что мы измеряем, в каких условиях, каких выводов ожидаем.
Я вот например ожидаю, что один клиент заблокируте всех остальных, либо вы изобретете свой велосипед, сделаете таймр, событие OnTimer и в нем будете в цикле бегать и раздавать каждому сокету по кусочку данных. Это максимум что вы сможете придумать для обхода проблемы )

Нет, он мертвый. Он не может в это время читать с диска, обрабатывать тысячи других событий, которые мы не прописали в WaitForMultipleObjects.
А мой SST - может запросто.


Ну как оно физически, да еще и под виндой я не знаю и знать особо не хочу. Я работаю на NodeJS/C++ итд а не на винде.


Ну а я, например не думаю. Если мне нужно что-то написать на ассемблере - я пишу на ассемблере и думаю только о нем. Меня не волнует, какой при этом будет байт-код. Меня волнует только ассемблерный код. Если я пишу на C++, тогда думаю только о нем, меня не парит что в это время делает компилятор. Если на Javascript - аналогично, думаю только Jvascript- ом. Если использую библиотеку - меня не волнует как и на чем она написана, меня волнуют только ее характеристики - производительность, простота использования и другие тонкисти.
От такого подхода продуктивность труда возрастает в десятки и сотни раз.


Я уже огласил. Конкретно мы будем проверять сколько займет памяти многопоточная реализация на C, а сколько однопоточная na Javascript. А Вы нам предлагаете измерить пропускную способность Вашего Жесткого диска или канала Ethernet.
Что будет за сервер и клиент? Все очень просто:
Клиент подключается к серверу и получает данные, сами данные игнорирует, подключений устанавливает не одно, а столько, сколько Вы захотите.
Сервер - читает с жесткого диска Ваш файл и выдает клиенту.

Реализации будет две сервера и клиента. Одна однопоточная на JS, вторая многопоточная на C. Обе совместимы, то есть Вы можете запустить клиент на JS а сервер на C или наоборот. И сможете проверить, сколько памяти(и проца) заняла каждая из реализаций.
Идет, все устраивает, будете тестить?

brag, спасибо за ответ. Но всё-равно не всё понятно.

1) Вот в этом месте я не могу представить - как происходит передача управления менее приоритетным задачам, при использовании SST. Пусть наша задача X имеет высший приоритет. Пусть нам в этой задаче надо сделать А, потом записать что-то во флешку, потом сделать B. Как это выглядит: сделали А, отправили с помощью DMA данные, по приходу прерывания от DMA сделали B. На время работы DMA управление можно отдать менее приоритетным задачам. Задаче Y управление отдать не можем - она прервана задачей X и к её стеку доступ мы получить не можем. Отдаем управление низкоприоритетной задаче Z. Если работу с ней мы закончим до прерывания DMA - всё будет хорошо - стек задачи Z нам уже не нужен, можем по прерыванию вернуться к X. А если Z будет работать ещё долго? Произойдёт прерывание DMA, как мы сможем восстановить контекст задачи X, если на вершине стека лежат данные задачи Z? А управление передать необходимо - ведь у X приоритет больше...
2) Даже если всё делать через очереди, то как в задаче X сохранить контекст (например локальные переменные) между A и B ? Это до меня пока не доходит


Сообщение отредактировал arhiv6 - Sep 8 2016, 10:17

arhiv6 , Вы путаете задачу и обработчик события. Это 2 разные понятия.
Обработчик может либо работать, либо не работать(выйти и освободить кадр стека), либо быть вытеснен обработчиком более приоритетного события, стек которого ляжет поверх вытесненного обработчика. Это по сути обычная функция и в моей реализации SST большинство времени планировщик именно это и делает - просто вызывает функцию.
Цепочка вызовов функций физически выглядит так: postEvent() -> scheduler() -> handler(). При чем функция postEvent - шаблонная inline, фактически будет вызван только scheduler() затем handler(). Операция очень быстрая и это от части заслуга компилятора.
А вот задача уже имеет свое состояние и для ее выполнения может понадобится куча событий, которые будут возникать хоть на протяжении целого года.
И состояние этой задачи и есть так называемый контекст, только это не регистры, как в многопоточной модели, а обычные переменные и обьекты C++.
А физически хранятся они там же, где и сама задача - в ячейке очереди задач. Это динамическая память. И она будет освобождена, как только задача завершит свою работу.

Посмотрите мой исходник, который я привел несколькими постами выше http://electronix.ru/forum/index.php?showt...t&p=1447897
DfMassEraseTask - это задача, вернее ее описание. Таких задач может быть создано хоть 100(ну на сколько хватит динамической памяти).
Ее контекст - это переменные:

Физически - это 3 указателя и 1 байт и того на Cortex-M3/M4 займет это дело 4 слова(из за выравнивания) - 16 байт. А сколько занял бы стек потока? Килобайт? или может 512 байт хватит? Как посчитать?

Вот тут то мы и начинаем докапываться до сути. Как говорит один мой друг(тоже и этих вэб программистов. PHPшников. Пытающийся что-то изобразить в эмбэддэд) "я слишком высокоуровневый программист чтобы думать об этом".
Вы и о движке JS наверно тоже никогда не думали )

Хорошо. При этом мы конечно же подразумеваем, что в остальных характеристиках эти серверы обеспечивают одинаковый уровень обслуживания.
Как то:
1. Одновременное обслуживание всех клиентов даже если один или несколько клиентов дали сереру задачу, требующую ожидания результата(путь это будет не математика а ожидание нажатия буквы J на клавиатуре или что угодно требующее ожидания.
2. Сравнимые возможности сервера по масштабируемости. Ну т.е. обслуживаем от 1 до 1000клиентов. Используем эффективно многоядерность системы и т.д..
3. Мы гигабайты памяти которые отожрет движок JS тоже подсчитывать будем или как? Да, с методологией измерений памяти и проца меня ознакомьте. А то это важный момент с кучей неочевидных моментов. )

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

Я не PHP-шник, я наоборот начинал с C, когда этого стало мало - полез в плюсы, теперь и этого мало - работаю на других более высокоуровневых языках, типа JS. И еще планирую переходить из плюсов на Rust.

Я знаю, как он работает поверхностно. Изучить его полностью - жизни не хватит, на столько он сложный.
Вы, когда на автомобиле едете, тоже думаете о там, как добывали руду из которой был получен металл, из которого потом ..... в итоге получился Ваш автомобиль?


Запросто, только сами будете J жать? Или предложите другой вариант?


Нагрузку даем по максимуму. 1 клиент это ни к чему. Многоядерность - ну если Вам так хочется - то запросто.


Конечно.


Да все очень просто - если винда - в диспетчере задач смотрим сколько памяти осталось, если линукс - команды htop или free. Да и мерить то нечего - какая система первой ляжет - та и проиграла


Ну вот Вы не видите, поэтому я сомневаюсь, что Вы его проведете. А если проведу я и покажу результаты, то Вы не поверите. Я к тому, что одну и ту же задачу, то есть наш сервер и клиент можно решить двумя способами - многопоточным и однопоточным. И производительность второго способа под серьезной нагрузкой будет в десятки раз выше.

brag, спасибо большое за разъяснение, теперь всё понятно. А можете посоветовать что почитать для тех кто хочет больше узнать про асинхронное программирование (не привязываясь к языку, чтобы упор был именно на алгоритмы)?

Сообщение отредактировал arhiv6 - Sep 8 2016, 10:54