-
- Полно их - Ruslan(06.12.2020 21:02, ссылка)
- Очевидно, что без механизма ожидания -- получается полная ерунда, которая ничем не лучше биглупа. Когда
событий станет много (типов событий, происходить им не обязательно)
-- всё время только и будет уходить на такие циклы проверки, как и
в биглупе. Зачем тогда сущность с громким названием "операционка"? fk0(7411 знак., 06.12.2020 14:41, ссылка, ссылка)
- Если вы про мой планировщик, то это скорее способ организации исходного текста (потому и sheduler), нежели претензия на кооперативную ОС. Dingo(1342 знак., 06.12.2020 21:29, ссылка, ссылка)
- Заглянул в причесанное Vit(149 знак., 06.12.2020 10:00)
- а напомните пожалуйста порядок вычисления аргументов для функции Zoro(58 знак., 06.12.2020 17:35)
- ЕМНИП, порядок любой. По чётным дням один, по нечётным другой. - SciFi(06.12.2020 17:41)
- Для конструкторов при этом -- строго слева-направо. - fk0(06.12.2020 18:46)
- ЕМНИП, порядок любой. По чётным дням один, по нечётным другой. - SciFi(06.12.2020 17:41)
- Во-первых p_tsk = &tasks[++i]. Во-вторых надоели идиоты:
оператор "запятая" ничем не плох, даже хорош по сравнению с
вариантами вроде ++*i-- так как порядок очевиден -- слева направо.
Оператор "запятая" от "точки с запятой" отличается только временем
жизни временных переменных (до "точки с запятой") и возможностью
использования в контексте выражения (а не оператора). В языке C
полезные применения: как раз избавление от ++*i--, возможность
записать последовательность fk0(247 знак., 06.12.2020 14:33)
- От идиота слышу. Твоё "во-первых" при выполняемой перед этим
проверке if ( i>=TAB_SZ ) break; вызывает обращение за границу
массива и это нужно вылечить, а не тут говном исходить. По логике
действительно нужен преинкремент. По тексту правильнее инкремент
делать до проверки на маскимальный индекс, а присваивание указателя
после. Работа с задачами не из списка, а из массива, в этой
интерпретации делается пробежкой по всему массиву, до первой
"задачи-пустышки". Обычно это Vit(601 знак., 06.12.2020 15:16)
- Спасибо за найденную ошибку. Начинал как вариант со списками,
сейчас склоняюсь к мысли вообще выкинуть этот изврат, ибо там, где
уместно применить "это-вот-всё", там списки лишние. Тогда будет
возможность дёргать задачу по номеру (из прерываний удобней,
например), а не по функции. - Dingo(06.12.2020 18:33)
- Считаю списки более удобным решением. Как минимум для отладки.
Невключение модуля - просто коммент строки, а не застирывание
массива, правка каких-то конфигов... Vit(936 знак., 06.12.2020 19:37)
- Если в реализации на списках из прерывания что-то делать, то мы
пошли обходить список, а с таблицей - номер N, обработай!( в свой
приоритет). Dingo(174 знак., 06.12.2020 20:35)
- Насчет "из прерывания что-то делать" - если говорим о добавлении задачи в список, то если не бояться дидлоков, для собственно быстрой операции добавления хранится указатель на хвост. Насчет дидлоков тоже можно решать быстрее, чем пробежать по списку, но это отдельный вопрос. Насчет соотношения приоритетов не понял. Наверно речь об идее с вытеснением. - Vit(06.12.2020 22:08)
- Списки хотят выделения/освобождения памяти, Dingo(959 знак., 06.12.2020 20:29)
- Что-то намешалось Vit(1765 знак., 06.12.2020 21:51, ссылка)
- Блин, не отпускает... Я ещё и о существовании XMACRO вспомнил. Dingo(1155 знак., 10.12.2020 08:31)
- ХЗ. Но в TASKLIST не видно запятых. Дальше не смотрел - Vit(10.12.2020 09:38)
- Вы правы, списки можно хранить и в таблице, например. Dingo(704 знак., 07.12.2020 07:59)
- Блин, не отпускает... Я ещё и о существовании XMACRO вспомнил. Dingo(1155 знак., 10.12.2020 08:31)
- Что-то намешалось Vit(1765 знак., 06.12.2020 21:51, ссылка)
- Если в реализации на списках из прерывания что-то делать, то мы
пошли обходить список, а с таблицей - номер N, обработай!( в свой
приоритет). Dingo(174 знак., 06.12.2020 20:35)
- Считаю списки более удобным решением. Как минимум для отладки.
Невключение модуля - просто коммент строки, а не застирывание
массива, правка каких-то конфигов... Vit(936 знак., 06.12.2020 19:37)
- Вот я и говорю про идиотов, ы которых набор каких-то догматических правил, мол "оператор запятая использовать нельзя" ("goto использовать нельзя") и т.п. Обосновывать свои догматы, конечно, они не могут, нечем. Мы о профессиональном программировании или о кружке пионеров? - fk0(06.12.2020 16:01)
- Приоритет во всех языках примерно одинаковый. Козырять несклерозом
не надо, но основные приоритеты знать надо. Иначе из-за количества
скобок код будет нечитаемый глазами. Надо знать про то, что
операторы взятия адреса и дереференса указателя выше по приоритету
арифметики (а ++ и -- ещё выше), и что логические операторы ниже
арифметики, и ниже оператора сравнения (который ниже арифметики). И
оператор присваивания -- ниже всех (кроме запятой). А тернарный
оператор выше fk0(66 знак., 06.12.2020 15:57)
- Представь, что знать-то знаю, а вот доверять не могу:) - Vit(06.12.2020 16:03)
- Спасибо за найденную ошибку. Начинал как вариант со списками,
сейчас склоняюсь к мысли вообще выкинуть этот изврат, ибо там, где
уместно применить "это-вот-всё", там списки лишние. Тогда будет
возможность дёргать задачу по номеру (из прерываний удобней,
например), а не по функции. - Dingo(06.12.2020 18:33)
- От идиота слышу. Твоё "во-первых" при выполняемой перед этим
проверке if ( i>=TAB_SZ ) break; вызывает обращение за границу
массива и это нужно вылечить, а не тут говном исходить. По логике
действительно нужен преинкремент. По тексту правильнее инкремент
делать до проверки на маскимальный индекс, а присваивание указателя
после. Работа с задачами не из списка, а из массива, в этой
интерпретации делается пробежкой по всему массиву, до первой
"задачи-пустышки". Обычно это Vit(601 знак., 06.12.2020 15:16)
- а напомните пожалуйста порядок вычисления аргументов для функции Zoro(58 знак., 06.12.2020 17:35)