Почему программы зависают?

Однако на практике это постоянно наблюдается, иногда парализуется вообще вся работа, и приходится перезагружать.

Примеры? Ты наверное путаешь с исчерпанием памяти, тогда ядро медленно ворочается и не может убить процесс, съевший всю память. При чём здесь вытесняющая многозадачность?

Пишут что в теории это как бы невозможно:

планировщик не понимает - зависла задача или в просто цикле считает биткоены. потому и снять сам он ничего не может.

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

Например потому что GUI обычно основаны на кооперативной колбековой многозадачности. Там есть главный цикл который обрабатывает очередь сообщений и вызывает соответствующие колбеки для обработки каждого сообщения. Если какой-то колбек завис то всё приложение зависнет.

Есть ещё зависания из-за ошибок использования примитивов синхронизации (мьютексы, семафоры и т.п.) и дедлоков.

Почему программы зависают?

у программистов лапки.

P.S. после очередного обновления Firefox на телефоне до версии 99, раз в сутки браузер тупо виснет насмерть, приходится прибивать руками.

бесит до жути, но даунгрейднуть уже не выйдет — пролюбится история и закладки.

тьфу.

А экспортировать историю и закладки можно? А потом импортировать в предыдущую.

в мобильном фаерфоксе экспортировать историю точно нельзя

Например потому что GUI обычно основаны на кооперативной колбековой многозадачности. Там есть главный цикл который обрабатывает очередь сообщений и вызывает соответствующие колбеки для обработки каждого сообщения.

это однозадачная event-driven архитектура. при появлении события система просыпается, обрабатывает его (выбором обработчика) в главном треде и засыпает. «обработчик кнопки» не является задачей!

это теоретически невозможно в общем случае — Проблема остановки

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

ему не надо ничего понимать, он должен просто передать управление. Он это в любом случае делает

может быть, но тогда вопрос в том почему выделение памяти никак не регулируется?

Даже если внутри программы кооперативная, снаружи планировщик все равно ее переключает, разве нет? самому GUY разве не выделяется процессорное время? У него безлимит?

Регулируется через cgroups.

в таком случае как допускается ситуация, когда памяти не хватает даже для планировщика?

«обработчик кнопки» не является задачей!

Опять же почему? Вполне себе задача. Если обработчик кнопки требует много времени на выполнение, то он может быть вручную разбит на части и если выполняемая часть не последняя, то она регистрирует следующую часть в очередь на исполнение.

Это происходит не на уровне OC, это другой слой абстракции. Сам процесс в котором выполняется обработчик прерывается как любая другая программа

Даже если внутри программы кооперативная, снаружи планировщик все равно ее переключает, разве нет?

Да, но это означает что другие программы могут продолжать работать без зависания. Конкретная программа вполне может зависнуть по разным причинам.

Короче это не имеет отношения к теме

Бывают ОС которые основаны на одном глобальном цикле обработки сообщений, например классический Оберон. Там один стек на всю систему. И тем не менее там можно достигнуть парелельного выполнения нескольких задач путём ручного разбиения на колбеки.

почему это не является? Все тоже самое.

И обработчик как правило не сработает пока не дождется очереди. То есть ты нажал кнопку, событие есть, но обработчик в этот момент только встанет в очередь на выполнение, поэтому реакция может быть вообще не сразу

Эффект глобального зависания может создавать например ожидание общего для многих программ события, например открытие и чтение файлов с одной и той же ФС.

Напоминаю, что «центральный планирующий механизм» - это тоже программа, и ее тоже писали программисты. А у них, как уже верно заметили в треде, лапки.

Это вот как раз один из явных недостатков вытесняющей многозадачности, потому что в кооперативной один процесс всегда имеет эксклюзивный доступ ко всей памяти

Но вообще то они заявляют что проблема доступа давно решена.

Я считаю что решить ее проще всего инкапсуляцией памяти в обьект с очередью, это как бы самоочевидное решение

Если обработчик кнопки требует много времени на выполнение, то он может быть вручную разбит на части и если выполняемая часть не последняя, то она регистрирует следующую часть в очередь на исполнение.

попробуйте компилятор gcc хотя бы мысленно разбить на хуки.

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

Это вот как раз один из явных недостатков вытесняющей многозадачности, потому что в кооперативной один процесс всегда имеет эксклюзивный доступ ко всей памяти

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

напомним что в вытесняющей многозадачности шедулер при появлении ивента высокого приоритета,и пробуждении треда высокого приоритета СРАЗУ переключает на него исполнение. такой скорости реакции в кооперативной просто не достичь… ну если только не ставить yield() после каждой строчки кода.

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

У Оберона компилятор быстрый так что компиляция одного исходника – одна задача.

У Оберона компилятор быстрый, так что компиляция одного исходника – одна задача.

ну если вы готовы терять сетевые пакеты, пока ваш хук-компилятор будет занимать проц… и потом я сказал про gcc.

ваши задачки - чисто модельные. частные случаи хорошей жизни.

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

У Оберона компилятор быстрый так что компиляция одного исходника – одна задача.

а где вообще применяют оберон? может за это еще и деньги платят?

А зачем тебе деньги? Продаваться кому попало не лучшая черта, прежде думай на кого работаешь, а уже потом сколько платят

Применение Оберона довольно закрытое. К сожалению там плохо дружат с открытым ПО. И существует куча разных реализаций Оберона, в том числе Активный Оберон с вытесняющей многозадачностью.

А зачем тебе деньги?

вопрос, ошеломляющий своей прямотой.

Почему программы зависают?

Потому что ПО стало ширпотребом и соответственно изменились принципы разработки, программисты лепят глюкодром потому что качество редко востребовано на деле, а не на словах.

В жирные годы обыватель вкладывает в модные понты, он вырыл могилу сам себе

Не настроенные cgroups, очевидно.

Но это фича появилась только в 2006 году, и она не контролирует все процессы, правильно?

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

Лимиты (ulimit) были ещё раньше.

Распределение памяти работает в режиме overcommit. Т.е. выделение физической памяти происходи не в момент malloc/new, а при попытке доступа к этой памяти. malloc/new дают только виртуальную память и могут дать больше чем есть в системе физической.

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

Подвох в том, что, обычно, если ОС не выдает новую память по запросу программы, она падает.

Распределение памяти работает в режиме overcommit.

И это вполне может привести к тому, что система встанет колом.

Подвох в том, что, обычно, если ОС не выдает новую память по запросу программы, она падает.

ОС или программа?

Т.е. выделение физической памяти происходи не в момент malloc/new, а при попытке доступа к этой памяти

а то, что при выделении блока менеджером кучи, туда НЕМЕДЛЯ прописывается его размер(вы как будете его деаллокировать по указателю?) и прочие штучки(зависит от реализации менеджера) - пофиг что ли? карочи. доступ к этой памяти идет уже внутри malloc, тогда причем тут некий overcommit?

Страница обычно 4 кб. Ну триггернёшь ты записью одну страницу, а остальные так и будут чисто виртуальными без физической памяти.

Почему программы зависают?

Потому что while true ...
/thread

i/o

Вообще то процессы вытесняются с помощью прерываний таймера процессора или системными вызовами (которые тоже прерывания). Процессы всегда вытесняются в linux, это закон!

Железки как раз риалтайм обычно, не? Потерять какое-то внешнее сообщение/данные или даже обработать их с задержкой там нельзя.

Железки как раз риалтайм обычно, не? Потерять какое-то внешнее сообщение/данные или даже обработать их с задержкой там нельзя.

можно, конечно! Называется «под нагрузкой выше пиковой»

Но это в ряде случаев фатально. Например, для автопилота обработка с задержкой «под нагрузкой выше пиковой» уже мало смысла имеет, даже если автопилот очень и очень крепкий с отдельным источником питания и выдержит лобовое столкновение, то вот пассажирам и остальным системам транспотра, вроде системы управления, уже будет по барабану на абсолютно корректное управление от автопилота.