Думаю, в процесса изучения курса "Операционные системы" порой возникает ощущение ненужности всех этих алгоритмов, стратегий и прочих архитектур, потому что зачем это прикладному программисту, который ниже int i не спускается. На деле это не так, и в данной статье я хочу это показать.Начну с обзора того, о чём уже писал в микроблогах (http://microblog.comp.susu.ac.ru/notice/448, http://microblog.comp.susu.ac.ru/notice/475). Вспомните, что такое процесс, зачем их планировать и как это можно сделать. Вспомнили? А теперь представьте электронную очередь со многими параметрами: тип обслуживания, требуемая степень конфиденциальности, срочность обслуживания и т.д. От того, что процессы заменили людьми, суть не поменялась: есть ряд задач и их надо выполнить в какой-то очерёдности. Вот и думайте, что тут применить: FCFS ли или что-то более интеллектуальное. Давайте попробуем поразмыслить:
Как видим, проблема достаточно суровая и не имеющая очевидного решения, однако знание операционных систем позволяет нам с чего-то начать. Эту же проблему, кстати, пытается решать теория массового обслуживания (и с экономической, и с математической точек зрения), сочетая в себе хитрую математику с практическими выводами и не являясь чисто прикладной дисциплиной. Второй пример хорошо освещён в статье на хабре. Кеш - по сути тоже память ограниченного размера. А раз размер участка памяти меньше размера данных, которые надо в нём хранить, то нужна стратегия замещения. Ну тут уж явно прослеживается связь с тем, что изучается на "Операционных системах". Выберите подходящий алгоритм либо руководствуясь полученными знаниями разработайте свой - и вперёд, к кешированию. Третий пример пришёл мне в голову сегодня утром. Вот возьмём любой сервис, выдающий пользователю предположения о том, что ему может понравиться, на основании действий других пользователей (например, тот же Last.fm). Как это можно реализовать? Один из вариантов - хранить взвешенный граф связей между сущностями, которыми оперирует сервис, при этом вес ребра показывает, какое количество (или процент) пользователей имеет эту связь. Дальнейший механизм очевиден: если пользователю что-то нравится, мы выбираем несколько наиболее весомых рёбер, исходящих из этой вершины, и предлагаем пользователю соответствующие сущности. Если пользователь согласен с предложением, то увеличиваем вес ребра, иначе уменьшаем. Можно хранить копию графа для каждого отдельного пользователя, тогда можно начать с полносвязного невзвешенного графа, постепенно отсеивая лишние рёбра и узлы. Подумав ещё, я вспомнил алгоритм замещения дальней страницы, хотя и имеющий противоположный механизм механизм действия, но эксплуатирующий ту же идею - построение рёбер между узлами на основании обращений одной сущности к другой. Вот и ещё один пример вполне себе прикладного применения системных алгоритмов (хотя, конечно, в операциях над графами нет ничего системного - это общематематические знания). Раздел "Файловые системы", пожалуй, один из самых близких к прикладной стороне - там рассматриваются вопросы сохранности данных, а это, пожалуй, важно и для не имеющих отношения к ИТ людей. Если посидеть и подумать, то можно найти ещё много примеров применения знаний, полученных на системных дисциплинах, в прикладной деятельности и даже в деятельности, далёкой от ИТ. Выводы:
|
Блог >