Наверное имелось ввиду, что если товар не со склада в Европе. Али везде сейчас делает свои склады, чтобы как раз конечный пользователь сам пошлину не платил, по факту пошлина уже в цене, такой же товар в Китае стоит дешевле.
Но если вы хотите купить товар, которого нет на складе в стране, то придётся платить пошлину вам, в России,пока что, только если сумма большая, например, запчасти для квадракоптера только из Китая.
Как в Европе не знаю. Но предполагаю, что они тоже не дураки, и товар, произведённый не в Европе, должны обложить пошлиной каким то способом.
Да, только у них план, и просто так вы им нафиг не нужны, вот если ориентировка или похож, то да. А возиться с челом за просто так им вообще не выгодно. Потом им же и прилетит за то что, план не выполнили.
Не там, не особо заморачивались, там вход и выход в trap, этакий единый обработчик прерываний занимает дофига времени. Но там фишка с переходом из машинного режима в обычный позволяет переключить контекст махом. Но это только с условием, что задачи не представляют из себя бесконечный цикл.
Вытесняющий планировщик разделит время на все процессы с одинаковым приоритетом (условно по 10млс на задачу), даже если там будет бесконечный цикл, всё равно всем достанется
Т. Е. По факту, всё задачи с равным приотетом делят своё время между собой, и просто бросают свою задачу на пол пути, планировщик вызывает другую. Ок. Но как бы это прямо реализация кооперативной многозадачности через вытеснение :)
При кооперативной многозадачности все приложения делят процессорное время, периодически передавая управление следующей задаче
Ок, я понял, что вы имели ввиду. Ну мы обычно просто задачи с равным приотетом делаем как раз, чтобы они друг друга не вытеснили и спокойно доделали своё дело. Но, Ок, теперь понял.
Принцип работы такой же, как у вашей и всех остальных, типа FREE RTOS, только вместо одного таймера после прерывания которого происходит поиск задачи, и если есть готовая, идет переключение, в случае в рантокомплишен, вызов задач происходит по событию, например, от того же таймера.
Если задача должна выполнятся раз в 1 мс, то заводится таймер, который раз в 1 милисекунду посылает событие задаче. После выхода из прерывания таймера вызывается планировщик, он ищет самую высокопритеную и запускает её.
События можно посылать хоть откуда, например, из прерывания, если пришёл пакет по UART， послали событие задаче по обработке пакета. Если она самая высокоприотетная, она вытеснит текущую, запустится, выполнит обработку пакета и вернёт управление текущей.
Если задачи имеют одинаковый приоритет, то пока не выполнится одна, вторая не запустится, но тоже самое будет и у вас, пока вы не поставите, что то типа Sleep, но по сути это означает, что вы уже сделали всё что хотели и следующую порцию будете делать через некоторое время. В рантукоплишен задаче это делается так - выполнить работу, запустить таймер и выйти, таймер через заданное время снова пошлет задаче событие. Она тут же запустится.
Т. е. всё тоже самое, но быстрее и значительно компактнее по ресурсам, как по памяти ОЗУ, ПЗУ, так и энергоресурсам, потомк что, зазря таймер не долбашит и не вызывает планировщик попросту.
Планировщик вызывается только тогда, когда реально есть готовые задачи. Остальное время можно, например, спать.
Но там есть несколько других проблем, например синхронизацию между потоками типа мьютексов так просто не сделать, поэтому основные примитивы синхронизации там - это запрет планировщика или прерываний, но если упороться то можно добавить Priority Ceiling Protocol для того, чтобы позволить задачам с высоким приотетом не блокироваться вообще. Ну или Инверсию Приоритетов делать
Нет, это не кооперативная, это вытесняющая многозадачность. Всё тоже самое, что и у вас, только задачи это не бесконечный цикл. Но они точно также вытесняются высокоприотетными задачами. Например, рисуете вы графику, это занимает 100мс, вас точно также вытесняют высокоприотетные задачи, которые исполняются чаще, скажем раз в 1 мс. И стек один у всех задач. Если вы из низкоприритетной задачи послали евент высокоариоритеной, то она вызовется тут же на этом же стеке. Если высоприотетная задача запускается по таймеру, то она запустится точно через такой же механизм как у вас, только стеки переключать не будет.
Да вообще, ну смотрите, если в РанТокоплишен, переключение делается примерно вот так:
while (nextTaskId < activeTaskId)
{
activeTaskId = nextTaskId;
CallTask(nextTaskId); // вызываем задачу и сбрасываем установленное событие
nextTaskId = GetFirstActiveTaskId(); // вдруг есть еще активные задачи
}
Т.е. по факту, просто вызываем функцию высокопритетной задачи прямо на этом же стеке.
То в обычной, придется все делать через PendSv и иже с ним, что пойдет после прерывания таймера и вызова планировщика - ну и соотвественно вызывать планировщик с каждым тиком тоже надо, а это тоже затраты. В РанТокоплишен можно на каждую задачу навешать свой таймер и он будет вызывать её чисто в тот момент когда она должна запуститься, т.е. планировщик будет вызываться только в момент, когда реально задача или несколько задач готовы.
Два стека позволяют существенно экономить на памяти. Их я использую, потому что cortex позволяет это делать. Конечно это не является обязательным условием, но если микроконтроллер это поддерживает на аппаратном уровне почему бы это не использовать
Наверное комментатор выше имел ввиду Task to complition операционные системы реального времени. Действительно два стека в этом случае как раз будет иметь перерасход памяти, поскольку вы под каждую задачу будете выделять стек с запасом, так как точно его вычислить практически невозможно. Когда же вы работает с одним стеком, можно границы максимально-возмодного стека определить практически точно.
В общем, все верно у вас, с комментатором выше не согласен. Можно было еще оптимизировать немного.
А так, такие операционки с двумя стеками контекст переключают долго, даже у вас это будет довольно долго, несмотря на оптимальный алгоритм. В Run to comlition там буквально пару строк на ассемблере, если событие приходит из прерывания, и после прерывания надо переключиться в высокоприоритетную задачу. А если переключаться просто из низко-приоритеной в высоко-приритеной - так вообще сразу практически, как только нашел. Но это, с учетом, если я правильно понял мысль вышестоящего комментатора.
Я думаю нужно выбрать что-то одно, вообще как-то заметил что на Урале с экологией как-то не очень, к сожалению советское наследие дает о себе знать.
На самом деле, не очень только в промышленных городах, типа Карабаша, Челябинска, Магнитогорска, но в общем экология и природа замечательная, главное от города отъехать.
Я летом наснимал чуток около Миасса, Златоуста, Кыштыма и Сатки
С какой точностью вымерали каждый байт в программах 30-летней давности, программистам сегодня такой тонкий подход и не снился.
Уродливости в прошлых вещах нет
Да, но уродливость есть, такой код невозможно поддерживать, потому что там столько триков, что даже самый умный супер программист ничего не поймёт, если автор ему не объяснит. А иногда и автор сам не понимает. Я вот смотрю свои программы под 51 контролёр и мотороллу 68000 и ничего не понимаю, а там даже не ассемблер, а Си. Но алгоритмы, которые я использовал и позволяли выверить каждый байт и сэкономить память или ускорить функцию я уже не помню.
И не знаю смогу ли я сам себе послать респект в прошлое. Сейчас я бы за такое уши бы оторвал, потому что не дай бог в таком софте надо будет что-то поменять. Да и вероятность ошибки там выше.
Сейчас, нужно применять стандартные, понятные решения, пусть они будут не такие оптимальные, но понятные и простые, так чтобы если что, программу можно было легко модернизировать и добавить новую фичу.
А всегда ли в коледже дают, то что надо конторе? Ведь даже процессы разработки в конторах разные, по-моему, достаточно увидеть, что человек имеет базу и может самостоятельно разобраться в чем то. Что он обучаем. Вот зачем спрашивать обход деревьев, если в 99℅ это не нужно?
Вы, что будете деревья обходить? Скорее всего вы будете использовать легаси код или библиотеки, где это уже все есть. А алгоритмы изобретать, это такое узкоспециализированное.
Чтобы убедиться что материал всех 4х лет хорошо усвоен
Вы же сами написали, что не знали и этого вам по всей видимости не давали, таким образом, вы просто пошли и набили руку на этих деревьях на онлайн тестах, но это ничего не говорит о том, усвоен материал или нет так как, через пару лет, если лет этого не используете, вы просто забудете всё и будете чист как стеклышко. В своё время я знал около 7-8 способов быстрого извлечения корня, когда писал на ассемблере для мотороллы. Но сейчас мне это не надо, у меня есть 1 ассемблерная команда, которая это делает. И я их все забыл.
Я думаю, что вопросы могут по неизвестному, но нужно смотреть не на то, знает человек это или усвоил за время обучения, а на то какой у него подход к решению задач, о которых он понятия не имел до собеседования, каковы его шаги. Что он будет делать в этой ситуации.
Не стоит ожидать от Джуна ответов на все алгоритмы и тонкости работы фреймворков.
Может быть вы специально искали работу, где нужны алгоритмы и знания вещей, которые в обычной жизни программист использует редко, но для Джуна это выглядит, как перебор.
Я не знаю как в других конторах, но по моему мнению, джун должен уметь думать, системно мыслить и быть обучаемым. А специфическим вещам и алгоритмам, которые используются он может научиться позже, во время выполнения задач. В общем, джун, это как стволовая клетка. Зачем задавать ему вопросы из совсем разных областей для меня загадка.
Вы описали любую работу. Так везде, только у нас ещё условия "домашние". Я работал на лесопилке в 90х, и поверьте, работа в IT это как отпуск. Там люди и пальцев и ушей лишались, а стресс каждый день запивали.
Ну да, работа она вообще такая штука, её надо делать. Полагаю, что даже работа по дегустации вин рано или поздно превратится в стресс. В общем, давно уже решил, что работу просто делаю и всё.
Ну если у вас строго статический буфер, то да. Вы можете не копировать сгенерированное изображение, а сразу выводить его, например передав указатель на буфер в ПЗУ в DMA
Я не знаю, это же секрет.
Насколько я понял, это военная нагрузка и её параметры, как и траектория засекречены. Отсюда и молчание.
Наверное имелось ввиду, что если товар не со склада в Европе. Али везде сейчас делает свои склады, чтобы как раз конечный пользователь сам пошлину не платил, по факту пошлина уже в цене, такой же товар в Китае стоит дешевле.
Но если вы хотите купить товар, которого нет на складе в стране, то придётся платить пошлину вам, в России,пока что, только если сумма большая, например, запчасти для квадракоптера только из Китая.
Как в Европе не знаю. Но предполагаю, что они тоже не дураки, и товар, произведённый не в Европе, должны обложить пошлиной каким то способом.
Почему?
Сдвигаем ящик на кирпичах влево
Ящик над ним вверх
Ящик перед ним вниз
Дальше нижний ящик ставим на место...
.. Ну там дальше просто уже.
Да, только у них план, и просто так вы им нафиг не нужны, вот если ориентировка или похож, то да. А возиться с челом за просто так им вообще не выгодно. Потом им же и прилетит за то что, план не выполнили.
Не там, не особо заморачивались, там вход и выход в trap, этакий единый обработчик прерываний занимает дофига времени. Но там фишка с переходом из машинного режима в обычный позволяет переключить контекст махом. Но это только с условием, что задачи не представляют из себя бесконечный цикл.
Тоже самое будет, что и у вас, только меджик намбер уйдёт 31. Ну и с - проблем не будет.
Т. Е. По факту, всё задачи с равным приотетом делят своё время между собой, и просто бросают свою задачу на пол пути, планировщик вызывает другую. Ок. Но как бы это прямо реализация кооперативной многозадачности через вытеснение :)
Ок, я понял, что вы имели ввиду. Ну мы обычно просто задачи с равным приотетом делаем как раз, чтобы они друг друга не вытеснили и спокойно доделали своё дело. Но, Ок, теперь понял.
Нам же нужен номер высыкоприоритетной задачи в массиве задач? Вот он как раз вернёт индекс задачи, дальше только вызвать её остаётся по этому индексу.
Принцип работы такой же, как у вашей и всех остальных, типа FREE RTOS, только вместо одного таймера после прерывания которого происходит поиск задачи, и если есть готовая, идет переключение, в случае в рантокомплишен, вызов задач происходит по событию, например, от того же таймера.
Если задача должна выполнятся раз в 1 мс, то заводится таймер, который раз в 1 милисекунду посылает событие задаче. После выхода из прерывания таймера вызывается планировщик, он ищет самую высокопритеную и запускает её.
События можно посылать хоть откуда, например, из прерывания, если пришёл пакет по UART， послали событие задаче по обработке пакета. Если она самая высокоприотетная, она вытеснит текущую, запустится, выполнит обработку пакета и вернёт управление текущей.
Если задачи имеют одинаковый приоритет, то пока не выполнится одна, вторая не запустится, но тоже самое будет и у вас, пока вы не поставите, что то типа Sleep, но по сути это означает, что вы уже сделали всё что хотели и следующую порцию будете делать через некоторое время. В рантукоплишен задаче это делается так - выполнить работу, запустить таймер и выйти, таймер через заданное время снова пошлет задаче событие. Она тут же запустится.
Т. е. всё тоже самое, но быстрее и значительно компактнее по ресурсам, как по памяти ОЗУ, ПЗУ, так и энергоресурсам, потомк что, зазря таймер не долбашит и не вызывает планировщик попросту.
Планировщик вызывается только тогда, когда реально есть готовые задачи. Остальное время можно, например, спать.
Но там есть несколько других проблем, например синхронизацию между потоками типа мьютексов так просто не сделать, поэтому основные примитивы синхронизации там - это запрет планировщика или прерываний, но если упороться то можно добавить Priority Ceiling Protocol для того, чтобы позволить задачам с высоким приотетом не блокироваться вообще. Ну или Инверсию Приоритетов делать
Нет, это не кооперативная, это вытесняющая многозадачность. Всё тоже самое, что и у вас, только задачи это не бесконечный цикл. Но они точно также вытесняются высокоприотетными задачами. Например, рисуете вы графику, это занимает 100мс, вас точно также вытесняют высокоприотетные задачи, которые исполняются чаще, скажем раз в 1 мс. И стек один у всех задач. Если вы из низкоприритетной задачи послали евент высокоариоритеной, то она вызовется тут же на этом же стеке. Если высоприотетная задача запускается по таймеру, то она запустится точно через такой же механизм как у вас, только стеки переключать не будет.
Вытесняющая
Да вообще, ну смотрите, если в РанТокоплишен, переключение делается примерно вот так:
Т.е. по факту, просто вызываем функцию высокопритетной задачи прямо на этом же стеке.
То в обычной, придется все делать через PendSv и иже с ним, что пойдет после прерывания таймера и вызова планировщика - ну и соотвественно вызывать планировщик с каждым тиком тоже надо, а это тоже затраты. В РанТокоплишен можно на каждую задачу навешать свой таймер и он будет вызывать её чисто в тот момент когда она должна запуститься, т.е. планировщик будет вызываться только в момент, когда реально задача или несколько задач готовы.
Я вот тут, ну совсем примитивный способ переключения описывал https://habr.com/ru/post/506414/
Наверное комментатор выше имел ввиду Task to complition операционные системы реального времени. Действительно два стека в этом случае как раз будет иметь перерасход памяти, поскольку вы под каждую задачу будете выделять стек с запасом, так как точно его вычислить практически невозможно. Когда же вы работает с одним стеком, можно границы максимально-возмодного стека определить практически точно.
В общем, все верно у вас, с комментатором выше не согласен. Можно было еще оптимизировать немного.
вместо отнимания 1
сделать так:
А так, такие операционки с двумя стеками контекст переключают долго, даже у вас это будет довольно долго, несмотря на оптимальный алгоритм. В Run to comlition там буквально пару строк на ассемблере, если событие приходит из прерывания, и после прерывания надо переключиться в высокоприоритетную задачу. А если переключаться просто из низко-приоритеной в высоко-приритеной - так вообще сразу практически, как только нашел. Но это, с учетом, если я правильно понял мысль вышестоящего комментатора.
На самом деле, не очень только в промышленных городах, типа Карабаша, Челябинска, Магнитогорска, но в общем экология и природа замечательная, главное от города отъехать.
Я летом наснимал чуток около Миасса, Златоуста, Кыштыма и Сатки
https://disk.yandex.ru/i/85gOGU-KDyjeAw
Да, но уродливость есть, такой код невозможно поддерживать, потому что там столько триков, что даже самый умный супер программист ничего не поймёт, если автор ему не объяснит. А иногда и автор сам не понимает. Я вот смотрю свои программы под 51 контролёр и мотороллу 68000 и ничего не понимаю, а там даже не ассемблер, а Си. Но алгоритмы, которые я использовал и позволяли выверить каждый байт и сэкономить память или ускорить функцию я уже не помню.
И не знаю смогу ли я сам себе послать респект в прошлое. Сейчас я бы за такое уши бы оторвал, потому что не дай бог в таком софте надо будет что-то поменять. Да и вероятность ошибки там выше.
Сейчас, нужно применять стандартные, понятные решения, пусть они будут не такие оптимальные, но понятные и простые, так чтобы если что, программу можно было легко модернизировать и добавить новую фичу.
А всегда ли в коледже дают, то что надо конторе? Ведь даже процессы разработки в конторах разные, по-моему, достаточно увидеть, что человек имеет базу и может самостоятельно разобраться в чем то. Что он обучаем. Вот зачем спрашивать обход деревьев, если в 99℅ это не нужно?
Вы, что будете деревья обходить? Скорее всего вы будете использовать легаси код или библиотеки, где это уже все есть. А алгоритмы изобретать, это такое узкоспециализированное.
Вы же сами написали, что не знали и этого вам по всей видимости не давали, таким образом, вы просто пошли и набили руку на этих деревьях на онлайн тестах, но это ничего не говорит о том, усвоен материал или нет так как, через пару лет, если лет этого не используете, вы просто забудете всё и будете чист как стеклышко. В своё время я знал около 7-8 способов быстрого извлечения корня, когда писал на ассемблере для мотороллы. Но сейчас мне это не надо, у меня есть 1 ассемблерная команда, которая это делает. И я их все забыл.
Я думаю, что вопросы могут по неизвестному, но нужно смотреть не на то, знает человек это или усвоил за время обучения, а на то какой у него подход к решению задач, о которых он понятия не имел до собеседования, каковы его шаги. Что он будет делать в этой ситуации.
Не стоит ожидать от Джуна ответов на все алгоритмы и тонкости работы фреймворков.
Может быть вы специально искали работу, где нужны алгоритмы и знания вещей, которые в обычной жизни программист использует редко, но для Джуна это выглядит, как перебор.
Я не знаю как в других конторах, но по моему мнению, джун должен уметь думать, системно мыслить и быть обучаемым. А специфическим вещам и алгоритмам, которые используются он может научиться позже, во время выполнения задач. В общем, джун, это как стволовая клетка. Зачем задавать ему вопросы из совсем разных областей для меня загадка.
Вы описали любую работу. Так везде, только у нас ещё условия "домашние". Я работал на лесопилке в 90х, и поверьте, работа в IT это как отпуск. Там люди и пальцев и ушей лишались, а стресс каждый день запивали.
Ну да, работа она вообще такая штука, её надо делать. Полагаю, что даже работа по дегустации вин рано или поздно превратится в стресс. В общем, давно уже решил, что работу просто делаю и всё.
Ну если у вас строго статический буфер, то да. Вы можете не копировать сгенерированное изображение, а сразу выводить его, например передав указатель на буфер в ПЗУ в DMA