3 марта

IBM дал производителям процессоров понять, что через пяток лет кому-то на рынке микропроцессоров не поздоровится. В сотрудничестве с Никоном IBM разрабатывает способ производства микросхем, который уже сегодня способен давать разрешение достаточное для создания элементов интегральной схемы в 0.08 микрона размером. И это лишь начало. Вплоть до 0.035 микрона сотрудники IBM проблем не видят.

Новая технология базируется на принципе электронной пушки - для создания структуры микросхемы используется уже не луч света, а поток электрончиков. Это позволяет достичь отличной точности, но сильно снижает производительность. При производстве своих суперкомпьютеров, как стало известно, IBM подобную технологию уже применял, но это случай специальный - большие объёмы производства не не нужны, можно и потерпеть. Теперь же вырисовывается способ сильно повысить производительность "пушечной" технологии. Настолько, чтобы технология могла использоваться и в массовом производстве.

Как именно - мне узнать не удалось, но есть подозрение, что всё очень просто - вероятно, скорость достигается параллельной работой нескольких пушек. На этом пути есть свои проблемы (хотя бы параллакс), но, видимо, решение найдено.

Практическое применение технологии - вопрос нескольких лет. По разным оценкам - от трёх до пяти.

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

Реклама
	Надежная защита и твердая платформа для Вашего бизнеса -- Microsoft Windows 2000 уже в России!

Эти зануды-аналитики уже так уверенно утверждают, что Микрософт выпустит офис под Линукс, что, наверное, уже проще выпустит, чем объяснять, почему не... :-) PR-щики Микрософта уже отвечают на эти вопросы с явным раздражением, а значит - действует. :-)

Unix как совокупность концепций, выкристаллизовавшихся в цельную и непротиворечивую систему, безусловно, определил направление развития отрасли на следующие десятки лет - минимум на три десятка. А там видно будет. Практически все системы, созданные после появления Юникса, черпают из него, явно или неявно, осознанно или нет, сотни мелких и крупных идей, принципов, механизмов...

Но есть один, который приживается за пределами Юникса с большим трудом. То есть почти вообще не приживается. Это - механизм порождения процессов.

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

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

Итак, в Windows 2000, к примеру, новый процесс (если исключить ухищрения и posix subsystem) можно запустить только запустив одновременно какую-то программу с точки старта. С начала.

Совсем иначе в Юниксе. В нём ортогональность соблюдена полностью. Запуск нового процесса - сам по себе, запуск программы в нём - сам по себе. Соответственно, два системных вызова. Первый говорит системе, что текущий процесс желает поделиться на два. Точнее - умножиться на два. После исполнения этого вызова получаются две совершенно идентичные копии изначального процесса. Они исполняют ту же самую программу с одного и того же места - того, что следует непосредственно за системным вызовом fork - тем самым, что создал вторую копию.

Есть только одно отличие между копиями - в одну fork возвращается с нулевым значением, в другую - с ненулевым. Кстати, это - единстенная известная мне функция, которая вызывается единожды, а возвращается дважды - в двух процессах по разу. :-)

Соответственно, проверив код возврата fork два процесса, отец и сын, могут (и, по идее, должны) вести себя по-разному. Как правило, в 90% случаев, процесс-сын по окончании fork сразу выполняет exec. Этот системный вызов говорит системе, что вот этот вот процесс, который вызвал exec, больше не хочет исполнять ту программу, что сейчас в его рамках исполняется, а хочет - другую. То есть процесс остаётся тот же самый, а программа в нём теперь будет работать другая. Новая.

Нетрудно заметить, что совокупность fork+exec в Unix даёт тот же эффект, что и запуск программы в "обычной" ОС. И чаще всего и используется. Но не всегда. По отдельности эти системные вызовы тоже имеют существенный смысл.

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

fork сам по себе применим, например, в программах, исполняющих запросы из Интернета. Основной "демон" ожидает запросы, например, на доступ к почтовому ящику (pop3). Получив запрос он выполняет fork, после чего "отец" продолжает ожидать запросы, а "сын" идёт выполнять данный конкретный запрос. Приэтом запуска новой программы не происходит - та же самая программа "раздваивается", и новая копия получает всё состояние старой - конфигурацию, например, заранее прочитанную из файлов настройки. Это удобно в программировании и эффективно.

Но такое использование - не слишком частый случай. Как я уже говорил, в 90% случаев после fork следует exec. Что вызывает, порой, нарекания программистов. Мол, зачем делать полную копию текущего процесса, если копию почти сразу придётся выкинуть в окно и загрузить на её место новую программу. Мол, потеря времени и ресурсов.

Когда-то это действительно было так - программа при fork копировалась полностью в памяти. Хуже того, в некоторых версиях это происходило с обязательным выкачиванием процесса на диск и закачиванием обратно. Беда просто.

С бедой боролись. Нетривиальным путём. В некоторых версиях Unix был системный вызов vfork (#define VIRUS_VFORK при сборке ядра, если память не изменяет:) - тот же fork, но предназначенный исключительно для ситуации fork/exec. Он работал нетривиально. Формально новый процесс запускался, но без копирования сегмента данных - он работал на сегменте данных отца, а сам отец на это время просто останавливался. От греха. Так происходило до тех пор, пока не происходил exec. И вот уж в этот момент генерировался новый сегмент данных. Да и кода - до этого момента код тоже использовался отеческий.

Коряво, но эффективно. Терпели, но пользовались. С оглядкой.

"Но, наконец, настал тот час" (С) кто-то там, когда это всё стало не нужно. И vfork остался лишь для совместимости. А fork в современных Юниксах перестал жрать ресурсы при использовании в паре с exec.

Как? Да элементарно. Ядро было переписано с использованием механизма по имени copy on write. Говоря проще, теперь при исполнении fork копия процесса не создаётся - процесс-сын продолжает использовать адресное пространство отца до тех пор, пока никто из них не попытается их общую память модифицировать. Как только случается попытка модификации, система вспоминает, что вообще-то этим двум процессам полагаются отдельные "квартиры" в памяти, и страничка, попытка модификации которой случилась, сразу дублируется. Одна копия - одному процессу, другая - другому.

Такой механизм позволяет при любом использовании fork минимизировать объём памяти, нужный двум родственным процессам. Если один из них сразу исполнит exec, не успев накуролесить, то копирование контекстов просто не успеет случиться. А не исполнит сын exec - копирование будет происходить постепенно, по мере надобности.

Так что Юниксовский механизм fork/exec, пожалуй, самый прогрессивный на сегодня подход к порождению процессов. И не менее эффективный, чем менее гибкие аналоги в традиционных ОС.