OSDev

На Си/Си++ можно написать хорошую программу, и это глупо отрицать. Но вот сделать это много быстрей и проще на более надёжных языках.



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

Что же касается восприятия в языках программирования... Я ведь тоже воспринимаю без всякого дополнительного анализа эти самые бегин-энды. Может, несмотря на плохое зрение (или благодаря ему), у меня лучше "графически-ассоциативное" восприятие? Я действительно схватываю "на лету" графические образы слов, не осознавая их явно (из-за чего могу читать с куда большей скоростью, чем 1000 слов в минуту -- естественно, когда не нужно глубоко вникать в прочитываемый текст, ну а когда надо вникать, там скорость падает из-за размышления над прочитанным, а не на собственно чтении). Это, ИМХО, могло бы объяснить, почему для меня сравнительно длинные стандартные языковые конструкции Паскаля воспринимать ничуть не сложней, чем краткие в Си.

Ну и тоже напоследок. Хотя я считаю (и, думается, вполне объективно), что Си намного хуже, чем Паскаль/Ада, в плане читабельности (особенно в объявлениях переменных, типов данных и т.п. -- из-за того, что в Си описание идёт то слева направо, то справа налево), я набрасываюсь на них всё же в первую очередь из-за низкой надёжности. Каким бы квалифицированным программист ни был, а случайных ошибок в Си можно понаделать (и делают) раз в 10 больше, чем на Паскале -- потому что уж очень многое разрешено. Не знаю, насколько объективны данные и как они получены, но где-то читал (возможно, в Википедии), что в адских проектах количество ошибок, которые приходится вылавливать во время отладки, в 9 раз меньше, чем в аналогичных по размеру и сложности проектах на Си/Си++. Потому-то я и меняю ассемблер на Аду, а не на Си: как уже говорил, если уж жертвовать эффективностью, то только в пользу надёжности и простоты не только кодирования, но, что куда важней, отладки программы. Так что "вселенским злом" являются не фигурные скобки

Да, нечто вроде этого. Однако подобный механизм (в RSX-11 называется асинхронными системными прерываниями -- AST; в OS/360 -- подпрограммами выхода) в хорошо известных мне системах не запрещает абсолютно ничего, и, в частности, не прерывает другие операции ввода-вывода: всё как работало, так и будет работать. На этих механизмах в означенных системах много что построено; например, взаимодействие с пользователем.



Возможно, мы друг друга не до конца понимаем. Ведь я говорю о работе, не связанной с текущей операцией ввода-вывода: задача что-то своё делает и одновременно с этим идёт ввод-вывод, т.е. достигается совмещение ввода-вывода и обработки, а значит, исключаются ненужные простои.



Ага, но тут ждёшь только тогда, когда это реально нужно, т.е. когда нет никакой работы, которую можно было бы сделать. Причём это ожидание эффективнее: если "там" надо регулярно опрашивать устройство, чтобы узнать, можно ли писать дальше, тот тут ждёшь завершения операции, для чего опрос не нужен: просто говоришь системе, что ждёшь, и она останавливает поток до выполнения условия ожидания (ну или до наступления таймаута, ежели таковой задан).



Ага, но дело-то в том, что в PDP-11 все быстрые устройства (диски и ленты) имели возможность прямого доступа к памяти и только так и работали; программная пересылка применялась лишь с медленными устройствами (терминалами, принтерами и т.п.). Ну а в мэйнфреймах ввод-вывод вообще всегда выполняется средствами так называемых каналов ввода-вывода -- по сути, узкоспециализированных процессоров, которые работают параллельно с основным, обращаются к нужным областям памяти и т.д. Основной процессор, запуская ввод-вывод, указывает каналу адрес устройства и адрес начала канальной программы -- и всё, дальше всё сделает канал, дёрнув ЦП, когда операция будет завершена. Соответственно, асинхронный ввод-вывод там очень эффективен. На ПК меня дико бесило отсутствие нормального прямого доступа к памяти: контроллер 8237 -- это жуткое ублюдство. Вот PCI-устройства уже могут выполнять его в стиле PDP-11, но они появились далеко не сразу.

Не быстрей!


Вот только не надо преувеличивать. Я согласен, в этих языках есть проблемы, но кроме некоторых неочевидных приоритетов ничего другого фатального на ум не приходит. Вольности с преобразованиями типов решаются включением всех Warning-ов в VS, после чего компилятор замучает тебя замечаниями на все потенциально опасные неявные преобразования типов.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

A = B | C; A = B || C;

Отсутствие логического типа, совершенно не совместимого с числовыми -- это ужас.

Неблокирующий ввод-вывод он на то и неблокирующий, чтобы проверка была не нужна. Операцию read() и write() можно сделать в любой момент. И, если, у операционной системы операция ввода-вывода (выполняемая с точки зрения прикладного кода асинхронно) выполнилась и есть данные в приемном буфере, которые нужно обрабатывать, то read() вернет эти данные немедленно. Если нет, тоже вернет немедленно, только данных будет 0. Тоже самое и с выводом. Если при записи есть достаточно места в выходном буфере (буфер будет писаться куда нужно асинхронно), тогда операция записи запишет все, что просили. Если места недостаточно, то операция запишет сколько сможет и вернет прикладной программе немедленный результат. Программа после этого сможет продолжать заниматься параллельно с выводом чем ей необходимо.

Операция select() вызывается, когда программе нечего делать и нужно ждать события от операционной системы, когда текущий ввод-вывод завершится. Чтобы программа могла либо начать обрабатывать полученные асинхронно данные, либо появилось место в выходном буфере и можно продолжить наработку данных.

Так что это та же асинхронность. Только API выглядит иначе.



Да, согласен. Ждешь, только тогда когда реально нужно. Нет данных на обработку или переполнился выходной буфер, а операционка предыдущие данные не успела отослать. Вот тогда и происходит select().



Вот насчет каналов согласен. Я уже и слово забыл как оно называлось. Это было реальное преимущество мейнфреймов. Но не могли же для настольных компьютеров сразу повторить архитектуру промышленных гигантов. Это сколько стоило бы? Каналы... представляли из себя устройства с отдельными процессорами, имеющими доступ к памяти мейнфрейма. Размером были с современную компьютерную стойку частенько.

Только вот беда: неблокирующий ввод-вывод на обычных файлах не работает.


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

Спорить не буду. Однако надо при этом упоминать конкретную версию операционной системы. Сама по себе идеология не мешает это реализовать.
В QNX6, например, такую штуку можно помнится включать/выключать опционально. Только у меня с этим были страшные глюки. (Операционная система загибалась при высокой нагрузке). Поэтому пришлось от асинхронности с файловой системой отказаться.

Скажем так: в общем случае не работает. По POSIX поведение не определено, и в мейнстримовых ОС вроде линукса и бсдей неблокирующий в/в на файлах работает как блокирующий. Софт, сделанный исключительно под QNX 6, использовать его, конечно, может, но в портабельных программах на него полагаться нельзя.

На самом деле, вполне могли. На младших моделях мэйнфреймов, типа наших ЕС-1022, -1035 и большинства других, каналы физически были частью процессора и обслуживались его аппаратурой (на микропрограммном уровне: например, выполняется какая-нибудь команда обычной программы и тут приходит сигнал о поступлении очередного байта от внешнего устройства; выполнение микропрограммы для команды процессора приостанавливается и выполняется соответствующая микропрограмма канала, после чего продолжается выполнение микропрограммы команды ЦП). Естественно, такое совмещение уменьшало производительность, однако обходилось очень дёшево в плане железа, а для программиста операции всё равно оставались истинно параллельными.

Далее, вспомним, что при создании ПК использовался не только собственно процессор, но и куча дополнительных микросхем: арифметический сопроцессор 8087, таймер 8253, контроллер прерываний 8259, контроллер прямого доступа к памяти 8237 и т.д. (позднее, когда создавали PC/AT, количество их даже возросло, и лишь ещё позже начали лепить первые чипсеты, объединяющие логику этих микросхем на одном кристалле). Соответственно, вместо ублюдочного 8237 вполне можно было бы создать микросхему, по своей логике подобной каналам мэйнфреймов. Либо можно было делать периферию в стиле PDP-11: быстрые устройства сами могут обращаться к памяти (что было сделано только для шины PCI, появившейся много позже); напомню, что PDP-11 -- минимашины, а не мэйнфреймы, и объём потребного для них железа много меньше. Так что с чисто технической точки зрения такая возможность была.

О чём и речь. Разговор-то начался с того, что именно мне в Унихах не нравится. Не в конкретном варианте (который, может, сделан криво), а в основной массе таких систем. Ведь в тех системах, которые я привёл как контрпример, всё это работает великолепно. (Что не мешает мне поругивать их все, но за частные вещи: например, RSX-11, делавшаяся под очень ограниченные ресурсы, а соответственно, имеющая ограниченный функционал, может показаться неудобной для некоторых "масштабных" задач, которые можно было решать на старших PDPшках).