Средства и методы разработки

Микрошедулер. Мягкие критический секции. Есть поток, который работает. Ценность времени у него неодинакова в разных точка программы. Где-то прерывать его нельзя - критическая секция. Где-то прервать его можно, но не надолго. Где-то время для него маловажно. Например -> описан вариант без критических секцй. Но надолго процесс там прерывать нельзя - будет фрагментация памяти. Пусть у каждого процесса будет некий дополнительный набор данных. Куда он пишет степень своей критичность ко времени. И зависимость этой критичности от неких глобальных событий. В описанном -> примере при походе к мягкой критической секции поток пишет в TCB (task control block) параметр - время критично. Но ничего не прерывается. Секцию прошел - снизил требования по времени - сделал нежесткую отдачу управления. Как работает шедулер. Вот случилось событие (прерывание) и шедулер отобрал управление у потока. Но при этом он смотрит - а какова критичность потока ко времени, и от чего она зависит. Ага, она высока, и зависит от того, были ли с этого момента обращения других потоков к логгеру. Но у нас есть еще более приоритетный процесс. Отдаем ему время, после возвращения, если по приоритету проходит, отдаем управление старому процессу, но взводим флаг нежесткой передачи управления. Насчет приоритета - если у отработавшего процесса было обращение к логгеру, то нужно срочно выделить квант времени первому процессу, чтобы он доделал свой блок, а затем прервать его. Первый процесс, дойдя до конца в своей псевдокритической секции, снижает требования по времени и делает некий вызов API. если у шедулера все напряженно - у первого процесса отбирают время и передают более приоритетному. Нет - первый процесс снова "на ходу". Конечно, сложность ОСи от такого сильно вырастет, но зато время процессора будет делиться куда более тонко. Не совсем понятно, сколько времени уйдет на такой дележ...