Триалогия

В статьях про прерывания и планировщик постоянно всплывала одна фраза: "возьми не ту блокировку, и система зависнет". Теперь речь о самих блокировках. Как только к одним и тем же данным обращается больше одной нити исполнения, а это происходит уже с прерываниями на одном ядре, тем более на двух - нужна защита. У меня (на самом деле не только у меня, это общеизвестные механизмы) два сорта блокировок, и разница между ними на удивление весомая. Хватит крошечного примера. Два потока увеличивают один...

В двух прошлых частях постоянно всплывал "тик таймера", запускающий переключение контекста. Но как этот тик вообще доходит до процессора? А нажатие клавиши, дочитанный сектор диска, пришедший сетевой пакет? Через прерывания! Это нервная система ядра, механизм, которым внешний мир получает право прервать процессор. Прерывание, это сигнал: "Стоп, займись мной немедленно". Процессор прерывает то, что делал, прыгает к обработчику, делает нужное и потом возвращается ровно туда, где был. Источников три:...

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

До сих пор речь всегда шла об одном-единственном потоке исполнения: кусок кода, который берёт память, лезет к железу, читает файл. Но на рабочем столе работают оконный менеджер, терминал, часы и десяток фоновых сервисов ядра, вроде бы все разом. А на одном процессорном ядре в каждый момент может работать только один поток. Трюк за этим стар и прост: молниеносное переключение. Замечание сразу: тут речь о том, как происходит переключение задач (Task Switch). Какая задача будет выполняться следующй,...

В статье про память я его уже анонсировал: аллокатор, который выдаёт каждому потоку его 256 КБ в области стеков. Вот он. И это славный пример того, что нет одного правильного аллокатора, а требование выбирает инструмент. Каждому потоку, работающему в ядре, нужен свой стек: там лежат локальные переменные, адреса возврата вызовов функций и сохранённые регистры, когда планировщик переключается с одного потока на следующий. Двум потокам нельзя делить стек, иначе они затопчут друг другу данные. Значит,...