Дополнительные вопросы, которые я задаю на экзамене
Длительная практика принятия экзаменов по курсу Работа на ЭВМ и программирование на мех-мат ф-те МГУ заставила меня сделать два довольно странных (по крайней мере, для меня) вывода:
На экзаменах я задаю довольно ограниченный набор дополнительных вопросов, знание которых я считаю необходимым для студентов, занимающихся программированием.
Студенты довольно устойчиво на эти вопросы не отвечают.
Я не берусь судить, почему студенты на эти вопросы не отвечают. Ссылки почти на все эти вопросы есть во всех курсах по данному предмету, читаемых на мех-мате, что, вроде бы, делает студентов обязанными знать ответы на эти вопросы. Но вот устойчивость незнания корректных ответов меня давно уже изумляет. Посему, я решил выписать эти вопросы и дать ссылки на их корректные, на мой взгляд, ответы. Вопросы не всегда имеют академически-точную формулировку, ну да мне так нравится их задавать. Не взыщите. Отсутствие нижеприведенных вопросов в билетах освобождает вас от ответственности за незнание ответов на них, однако, все же, сильно рекомендуется для вашего же блага (глобального, а не локального) ответы на эти вопросы знать.
Очень бы хотелось, чтобы вы знали, что самый раздражающий преподавателя аргумент студента на экзамене: “а нам так на лекциях рассказывали”. Так говорить нельзя. Вы уже взрослые люди и должны иметь свою точку зрения на обсуждаемые вопросы. Даже если вы несете чушь (по мнению экзаменатора) и при этом считаете, что вам так рассказывали на лекции, то это – ваши проблемы. Разумеется, здесь не идет речь о вещах, не поддающихся разумной проверке на месте. Здесь говорится о вопросах, проверить ответы на которые можно из логических соображений.
К сожалению, мир устроен так, что людям свойственно ошибаться. А лекторы – люди. Во всех, известных мне лекциях есть ошибки. Это – нормально. Я исхожу из того, что если вы пересказываете такую ошибку, то это – опять же, ваша проблема. Вы учитесь на мех-мате, а не в техническом ВУЗе. Наша основная специальность – думать. Если не можете, то вы не предназначены для этого ф-та.
Сначала я напишу вопросы. Прочитайте и поймите, на что вы можете ответить. Ссылки на ответы я приведу в конце документа.
Вы должны знать язык С. Без этого экзамен становится бессмысленным. Любой отвечаемый вами вопрос должен интерпретироваться небольшими примерами на языке С (С++). Не знаете языка – зубрите примеры. Хотя бы в этом случае у преподавателя будет спокойная совесть, когда он будет ставить вам отметку >2, при том, что, по его мнению, вы этой оценки недостойны. И не думайте, что хоть какому-то вменяемому преподавателю доставляет удовольствие ставить двойки. Ведь двойка, это – признание того, что он (преподаватель) выкинул кучу времени на учебу студентов впустую. А что есть дороже времени?
Любимый вопрос по языку: как реализовать функцию, которая при первом вызове делает что-то одно, а при всех остальных – другое. К этому вопросу примыкает вопрос о времени жизни о области видимости переменных в языке С/С++. Кстати, для меня было большой неожиданностью узнать, что ответ на вопрос о времени жизни переменных в языках С и С++ различный.
Механизм обработки прерываний, хотя бы на примере той машины, за которой вы в данный момент сидите.
Виртуальная память в приличной ОС (можно, конечно, сказать UNIX, Linux, WindowsXXXX, но это не существенно). Обычно, вопрос задается в виде: к каким конкретным машинным командам [примерно] приводит кусок кода на С в приличной ОС: char *s; s=12345; *s=123;
Кэш-память. Ассоциативная кеш-память. Объяснения должны быть вплоть до уровня конкретного алгоритма вычисления адреса в Кеш-памяти по адресу в физической памяти.
Механизм передачи параметров в функции. Все вплоть до конкретных машинных команд. Вы должны знать ответ на банальный вопрос: а вызвать функцию, это – дорого? Т.е. насколько собственно вызов функции замедляет работу программы?
Сколько может быть в программе локальных переменных? Например, какова максимально возможная глубина рекурсии вызова функции void f(int x); при тех ограничениях и допущения, которые вы сами хотите ввести. Еще лучше, если вы знаете существующие где-либо ограничения.
Алгоритмы сортировки. Ну, самый убойный вопрос здесь – QuickSort. Существует элементарный способ завалить плохого студента. Надо попросить его рассказать хоть что-то, что он знает. С очень большой вероятностью студент выберет сортировку именно этим методом. Все. Можно потирать руки. Завалить на этом примере можно примерно 80% студентов (изо всех!). Есть два этапа заваливания: а)сначала надо попросить рассказать сам алгоритм в общем (если студент плохой, то он, наверняка, точно его не помнит); б)надо попросить точно выписать алгоритм. Второй этап – гроб. При, относительно, не сложной идее алгоритма, его конкретная реализация допускает море возможностей сделать фатальную (и для алгоритма, и для студента) ошибку.
Теорема о времени работы алгоритма QuickSort. Надо четко понимать, что следующую формулировку этой теоремы вам не зачтет никто: Среднее время работы алгоритма QuickSort равно O(n log2n), где n – количество элементов в массиве. Среднее в каком смысле? Отвечать тут можно по-разному. Признаюсь, что не любой ответ, вычитанный из лекций, читаемых на мех-мате, меня устроит.
Формулировка теоремы о наименьшем времени работы алгоритмов, основанных на сравнениях. Надо четко понимать, что следующую формулировку этой теоремы вам не зачтет никто: Не существует алгоритма, способного отсортировать массив из n элементов за время, меньшее O(n log2n).
Понятие нижних и верхних оценок. На мой взгляд (только на мой!), это – главные понятия читаемых курсов. Не уверен, что этот вопрос есть во всех мех-мат-овских курсах по данному предмету. Со всеми вытекающими выводами. Однако, с философской точки зрения, ответ на эти вопросы эквивалентен ответу на вопрос: что такое хорошо и что такое плохо. В конкретной области. Разве может быть что-то более важное?
Хеширование. Любимый вопрос (на мой взгляд, совсем простой): надо рассказать, как реализовать исполнитель множество на основе хеширования (любого), который позволяет заносить слова в множество и определять: есть слово в множестве, или нет. Все это в терминах языка С.
Семафоры. Здесь самый главный подвопрос: а зачем, вообще, это надо? Почему нельзя заменить такое громкое понятие семафора глобальной (в каком-то смысле) переменной и функциями на языке С, которые проверяют значение этой переменной, а потом делают соответствующие действия. Или, все-таки, можно? На самом деле можно. Да вот только, сомневаюсь, что, по крайней мере, на нашей кафедре найдется человек, кто с ходу выпишет соответствующие алгоритмы. Я с ходу тоже не выпишу.
Ничем помочь не могу. Если не потратили n-тое количество часов на программирование, то ситуация не лечится. Есть редкие примеры, когда человек эти часы потратил, но это не помогает. Чтобы не помогало совсем – такого не видел, но чтобы помогало плохо – видел. В последнем случае стараюсь войти в ситуацию.
Решается с помощью локальных статических переменных. Надо иметь в виду, что использование глобальных переменных – плохой тон. На самом деле, использование, вообще, статических переменных, это – всегда плохо (ну, например, статические переменные делают невозможным переход на использование написанных вами функций в многопоточной программе).
Вполне конкретно, но не говорится, а как же возвращаться из прерывания? : http://www.opennet.ru/docs/RUS/os_unix/glava_12.html Очень подробно и конкретно: http://www.xserver.ru/computer/computer/proc/1/4.shtml . Конечно, не надо учить названия регистров и все тонкости. Я их, лично, не помню. Не надо читать Википедию!!! Крайне неинформативно!!! Вот мой вариант ответа, подходящего для большинства современных платформ (не для всех!!!, но это не существенно)
Прерывания Процесс выполнения программы сводится, в конечном счете, к следующему. Программа представляет собой набор последовательно записанных команд. Как правило, существует регистр, в котором хранится номер текущий команды. Элементарный шаг выполнения программы называется циклом. В процессе исполнения цикла происходит выборка команды и исполнение команды. Сразу после выборки команды счетчик команд увеличивается так, что он указывает на следующую команду.
Базовым понятием при описании принципов действия ЭВМ является прерывание. Бывают прерывания четырех типов:
Программные прерывания
Аппаратные прерывания
Прерывания ввода/вывода
Прерывания по таймеру
При исполнении прерывания происходит приостановка выполнения основной программы, данные о адресе текущей команды (регистр с адресом текущей команды) и состояние системы (например, регистр флагов) сохраняются (как правило, в стек) и происходит передача управления на программу обработки прерывания. После ее завершения состояние системы восстанавливается, и управление передается на прерванную команду. Отметим, что часто перед обработкой прерывания приходится сохранять гораздо больше данных. Например, обычно сохраняются значения всех регистров. Но это уже - забота функции обработки прерывания.
Очевидно, что прерывание не может наступать в произвольный момент. Поэтому в цикл выполнения программы добавляется еще один этап: проверка наличия прерывания. Именно на этом этапе будет возможен вызов прерывания. Если его поместить после этапа исполнения команды, то в стеке надо будет сохранить текущий регистр с адресом исполняемой команды (он увеличился сразу после выборки команды), а после завершения прерывания надо вернуться по этому адресу.
В процессе выполнения некоторых прерываний следует запретить вызов других прерываний. Этот процесс называется блокировкой вызовов прерываний. Вызов прерываний всегда блокируется при, собственно, вызове прерывания, когда необходимые данные загружаются в стек и происходит переход к процедуре исполнения прерывания.
Часто прерывания реализуются с помощью таблицы прерываний. Таблица прерываний представляет собой массив, в каждой ячейке которой хранится адрес процедуры обработки прерывания и, возможно, некоторая дополнительная информация. В этом случае каждое прерывание ассоциируется с некоторым номером n и вызов прерывания n ассоциируется с вызовом процедуры обработки прерывания, адрес которой находится в ячейке таблицы прерываний n.
Прерывания очень полезны, например, для обработки операций ввода/вывода. Эти операции весьма медлительны, поэтому было бы разумным (на самом деле так происходит далеко не всегда) запустить эту процедуру и вернуть управление текущей программе. Далее, когда от процессора будет требоваться вмешательство в процесс ввода/вывода (например, данные попали, наконец, в буфер ввода/вывода), то вызовется прерывание, которое обработает эти данные и вернет управление текущей программе.
Хотелось бы услышать что-то включающее следующее.