Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?
Не надо искать в моем комментарии цинизм, сарказм или еще какой негатив — я его туда не закладывал. Это просто всплеск эмоций в связи с нахлынувшими воспоминаниями по теме (пикрелейтед).
Любой код после DI перестаёт исполнять прерывания, можно на контроллере таймер выключить, и сказать, — «ой ваш АРМ перестал задачи переключать», а можно ещё и питание выключить. Любой код после порчи его перестаёт работать.
Ну попробуй на АРМе из пользовательского пространства ОС сделать DI или выключить на контроллере таймер или испортить код.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий.
По этой логике сложных программ не существует, ибо все они состоят из простых логических действий.
Прикол в том, что ты действительно реализовал самый простой циклической шедулер типа Round Robin. А есть более сложные, учитывающие приориеты и группы приоритетов, с разной вычислительной сложностью и т.п.
Речь не о ММУ или защите от говнокода/злоумышленника. Речь об удобстве распределения вычислительной нагрузки между разными задачами. Ваш КО, обращайтесь.
Любой код после DI перестаёт исполнять прерывания, можно на контроллере таймер выключить, и сказать, — «ой ваш АРМ перестал задачи переключать», а можно ещё и питание выключить. Любой код после порчи его перестаёт работать. Это просто качество написания кода, и поточность тут не играет никакой роли. Процесс нужно прибивать только после того как код этого процесса написан с учётом того, что он может сделать DI, или попортить память, — не более чем качество написания кода.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий. Можно трижды написать «он простой и наколенный», но от этого ничего не изменится. Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?
О да! Многопоточность (особенно на спеке)- это офигенно интересная тема. Простейший наколеночный шедулер и ты — властелин мира (до первого DI или порчи памяти, бгг). Программа содержит ошибку и зациклилась? Не беда- процесс всегда можно прибить без последствий:)
Отличное название, слушай. ты не против я его у тебя упру? Я теперь эти процедуры буду называть «Шинкованные сквозные процедуры». А представляешь, возможно что этого метода есть нормальное название. Помню как мне в детстве все говорили — «вот есть объектно-ориентированное программирование, это тебе не ZX-Spectrum», а потом я узнал, что и так половина всего, что я вижу это оно и есть, просто кто-то этому дал «страшное» название.
Я понимаю, что возможно у меня фраза «сквозные процедуры» прижилась ещё с детства, я их тогда так назвал. Допустим, чисто как пример, у нас есть что-то откуда мы берём стрим данных, например это модем по UART'у, допустим что у нам надо принять байт и его обработать, например разобрать АТ команды. Вызов такой процедуры будет в цикле:
LOOP ...что-то
CALL PARS_MODEM
...что-то
JP LOOP
Вот процедура PARS_MODEM будет всегда однопроходная. В ней будет хранится текущая позиция исполнимого кода, и там никогда не будет циклов. Да же не текущая позиция кода, а текущее полодение в наборе мелких участков кода. Пришёл байт, проверили закончил ли он строку, нет, вышли, если да, проверили строку, вышли. Вошли снова, проверили что надо сделать со строкой, если ответить, ответили, вышли, переключили снова в ожидание окончания строки. Таким образом если у меня будет 10 модемов, то процедура PARS_MODEM, будет вызвана 10 раз, но со ссылкой на описание нужного UARTа, или другого интерфейса. то есть в таких процедурах допускается выполнение чего-то ёмкого, но крайне редко, или эти ёмкие части кода будут исполняться поэтапно, что бы вылетать из процедуры и давать работать соседней процедуре.
Спасибо, я примерно так и думал, но опасался что-то упустить из вида.
У меня только одно ограничение, которое я как-нибудь обязательно разрешу: сейчас у меня в скрипте блокирующие команды перемешаны с неблокирующими. Это не очень существенное ограничение, но оно означает, что во время распаковки (блокирующая команда) я не могу фиксить эффекты (там команды короткие, по сути, не блокирующие). Скорее всего, я решу эту проблему выносом неблокирующих команд, или даже целиком интерпретатора скрипта, в обработчик прерываний, что можно интерпретировать, с небольшой натяжкой, как третий поток. Но пока что не было ещё ситуации, чтобы мне РЕАЛЬНО захотелось это сделать.
А что ты называешь сквозными процедурами? Я не слышал раньше такой термин.
Лёша, но это честные потоки. В данном примере количество потоков ограничено до четырёх. В этих потоках только нет MUX'ов, а остальное всё по классике жанра.
Примеры привести очень сложно, по скольку у меня львиная доля работ это демка. А тут за всю историю я не нуждался в более чем двух потоков, просто это не нужно. Что для демки надо? На заднем плане что-то считать и контролировать логику на переднем плане, ну а на прерываниях показывать эффекты. Вообще я давно не использовал потоки, по скольку мне приятнее сквозные процедуры, и если бы не SYNCHRONIZATION и gift WAYHACK, я бы не вспомнил о них.
Вот в WAYHACK на первом потоке происходит расчёт эффекта, а на втором потоке печатается текст, рассчитываются координаты букв, создаётся предварительная анимация.
В SYNCHR'е потоки пускаются в части с иконками и летающем кубике. Пока все смотрят на выпадающего Бина, в соседнем потоке подготавливается куб.
Ещё эти потоки, и это было впервые со страницами, были сделаны в игре WonderLust, там пока кто-то смотрит интро, выбирает какими клавишами играть, — на втором потоке генерируется лабиринт.
Прости, но в тематике Speccy, сложно применять более серьёзно потоки, ведь мы все привыкли писать код так, что бы он по сути не требовал потоков. Лёша, просто ты это прошёл, поэтому тебе проще использовать то, что у тебя наработано. И ты прав, я начиная с игры WonderLust не усложнял потоки, просто не нужно больше. Вообще когда я впервые встретился с потоками, увидел, что в большинстве случаев люди(PC) их пихают в местах где это ну совсем не надо.
Поэтому, да более чем два потока я не вижу применений.
Довольно прикольно, но настолько актуальна именно «честная» многопоточность на спектруме? Все мои ядра начиная с Down по сути двухпоточные, в том смысле, что ядро может исполнять код (запирающий) в как бы основном процессе, а практически вся риалтаймовая визуализация сделана у меня обычно вызовом из прерывания, т.е. неким независимым тредом. То есть у меня совершенно обычное дело показывать эффект (в прерывании) и распаковывать что-то используя остатки времени во фреймах.
Наверное, это какой-то вышел мутный вопрос. Вот чёткий вопрос: приведи, пожалуйста, 2-3 (можно больше!) примера, желательно из своих дем, где ты реально совмещаешь несколько потоков (т.е. больше двух), чтобы нам лучше понять, какого рода удобства это предоставляет в работе. Пойми правильно, я тебя не критикую; процессы переключения контекстов у тебя выглядят очень знакомо, довольно похоже на то, что пришлось закодить в ядре мне. Но хочется чётко понять возможную мотивацию дальнейшего усложнения ядра.
Ну попробуй на АРМе из пользовательского пространства ОС сделать DI или выключить на контроллере таймер или испортить код.
По этой логике сложных программ не существует, ибо все они состоят из простых логических действий.
Прикол в том, что ты действительно реализовал самый простой циклической шедулер типа Round Robin. А есть более сложные, учитывающие приориеты и группы приоритетов, с разной вычислительной сложностью и т.п.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий. Можно трижды написать «он простой и наколенный», но от этого ничего не изменится. Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?
Здорово что ты поднял эти вопросы на самом деле, прямо захотелось почитать немного теории по этому поводу. Чтобы поменьше велосипедов было.
Удаление потока не используешь?
Вот процедура PARS_MODEM будет всегда однопроходная. В ней будет хранится текущая позиция исполнимого кода, и там никогда не будет циклов. Да же не текущая позиция кода, а текущее полодение в наборе мелких участков кода. Пришёл байт, проверили закончил ли он строку, нет, вышли, если да, проверили строку, вышли. Вошли снова, проверили что надо сделать со строкой, если ответить, ответили, вышли, переключили снова в ожидание окончания строки. Таким образом если у меня будет 10 модемов, то процедура PARS_MODEM, будет вызвана 10 раз, но со ссылкой на описание нужного UARTа, или другого интерфейса. то есть в таких процедурах допускается выполнение чего-то ёмкого, но крайне редко, или эти ёмкие части кода будут исполняться поэтапно, что бы вылетать из процедуры и давать работать соседней процедуре.
У меня только одно ограничение, которое я как-нибудь обязательно разрешу: сейчас у меня в скрипте блокирующие команды перемешаны с неблокирующими. Это не очень существенное ограничение, но оно означает, что во время распаковки (блокирующая команда) я не могу фиксить эффекты (там команды короткие, по сути, не блокирующие). Скорее всего, я решу эту проблему выносом неблокирующих команд, или даже целиком интерпретатора скрипта, в обработчик прерываний, что можно интерпретировать, с небольшой натяжкой, как третий поток. Но пока что не было ещё ситуации, чтобы мне РЕАЛЬНО захотелось это сделать.
А что ты называешь сквозными процедурами? Я не слышал раньше такой термин.
Примеры привести очень сложно, по скольку у меня львиная доля работ это демка. А тут за всю историю я не нуждался в более чем двух потоков, просто это не нужно. Что для демки надо? На заднем плане что-то считать и контролировать логику на переднем плане, ну а на прерываниях показывать эффекты. Вообще я давно не использовал потоки, по скольку мне приятнее сквозные процедуры, и если бы не SYNCHRONIZATION и gift WAYHACK, я бы не вспомнил о них.
Вот в WAYHACK на первом потоке происходит расчёт эффекта, а на втором потоке печатается текст, рассчитываются координаты букв, создаётся предварительная анимация.
В SYNCHR'е потоки пускаются в части с иконками и летающем кубике. Пока все смотрят на выпадающего Бина, в соседнем потоке подготавливается куб.
Ещё эти потоки, и это было впервые со страницами, были сделаны в игре WonderLust, там пока кто-то смотрит интро, выбирает какими клавишами играть, — на втором потоке генерируется лабиринт.
Прости, но в тематике Speccy, сложно применять более серьёзно потоки, ведь мы все привыкли писать код так, что бы он по сути не требовал потоков. Лёша, просто ты это прошёл, поэтому тебе проще использовать то, что у тебя наработано. И ты прав, я начиная с игры WonderLust не усложнял потоки, просто не нужно больше. Вообще когда я впервые встретился с потоками, увидел, что в большинстве случаев люди(PC) их пихают в местах где это ну совсем не надо.
Поэтому, да более чем два потока я не вижу применений.
Наверное, это какой-то вышел мутный вопрос. Вот чёткий вопрос: приведи, пожалуйста, 2-3 (можно больше!) примера, желательно из своих дем, где ты реально совмещаешь несколько потоков (т.е. больше двух), чтобы нам лучше понять, какого рода удобства это предоставляет в работе. Пойми правильно, я тебя не критикую; процессы переключения контекстов у тебя выглядят очень знакомо, довольно похоже на то, что пришлось закодить в ядре мне. Но хочется чётко понять возможную мотивацию дальнейшего усложнения ядра.