Аналогично, под влиянием тех же журналов заинтересовался советскими программируемыми калькуляторами. Написал письмо в редакцию одного из этих журналов, чтобы узнать, где его можно купить. Уговорил родителей, которые купили мне МК-61, для которого я и написал свои первые программы. Дальше работал с БК-0010, ZX-Spectrum 128 на разных практикумах и в школе, параллельно осваивая «Фортран» и ассемблер EC ЭВМ в одном из НИИ в СПб (ЛИИАН). Закончив школу, сразу же пошел работать программистом, получив возможность программировать для IBM PC в 1989 году (под MS-DOS). Имея опыт работы с 32-битными мэйнфреймами (EC) c нетерпением ожидал, когда же PC станут 32-битными и где-то с 1991 года писал программы уже под всякие 32-битные DOS-extenders, а затем под OS/2. :)
То, что предлагают авторы фильма — это ни что иное, как вариант коммунистического общества (не путать с социализмом). Коммунизм утопия, его невозможно построить в реальном мире — все попытки построить коммунизм приводили к созданию тоталитарных социалистических государств. Но я берусь утверждать даже большее — его не просто невозможно построить в реальном мире, но даже если бы его все-таки построили, то этот общественный строй привел бы человечество к деградации и вырождению (или люди сами бы от него отказались).
1. Фильм — пропаганда коммунизма, все практические попытки построить который — провалились.
2. При современном уровне развития технологий даже технически невозможно полностью избавить человечество от потребности в ручном труде, пока что это утопия. Но допустим, что это стало возможным, тогда:
3. Ручной труд просто полностью сменится интеллектуальным трудом, причем по-разному оплачиваемым в зависимости от результатов. Нельзя избавиться от денег или их эквивалента в виде неравного доступа к благам цивилизации. Стремление к превосходству — движущая сила прогресса и если убрать этот фактор, то человечество деградирует. Деградировав, оно не сможет поддерживать функционирование машин, которые его обслуживают. Если же машины будут наделены искусственным интеллектом и смогут поддерживать себя сами без помощи людей, то отпадет не только необходимость в деньгах и труде у людей, но и потребность в существовании людей на данной планете. :)
Какие к черту законы в такой системе? Тот, кто будет контролировать ее серверы, объявит преступником любого гражданина, какого только пожелает и ни у кого не будет никаких сомнений в подлинности вымышленной истории его преступлений, если все привыкнут доверять системе. Такая система могла бы потенциально быть оправданной только при сегментации баз и жесточайшем общественном контроле за ее кодом, за машинами, на которых она работает и так далее, но я даже не представляю, как в реальности можно было бы осуществить подобный контроль на всех этапах разработки и развертывания. Без тотального общественного контроля подобная система неизбежно ведет к тоталитарному обществу. :)
Кстати военный бюджет России растет и весьма существенно, в том числе и в пересчете на валюту и проценты ВВП. При этом сами военные жалуются на развал армии. Какой можно сделать из этого вывод? Аппетит у бандитов и гебистов растет. А сокращение личного состава позволит еще больше увеличить их доходы.
1. Выпейте успокоительного, чтобы не писать о том, что «политические силы США» давят на инвесторов mail.ru.
2. Вообще-то прослушивание со стороны американских спецслужб – это наименьшее из зол, если сравнивать его, например, с подслушиванием российскими спецслужбами. Так как последних интересует отнюдь не только проблема терроризма, но и многое другое… :) Я уж не говорю о потенциальном прослушивании со стороны самого mail.ru, как с ведома, так и без ведома руководства.
3. А есть ли российская альтернатива GIPS сопоставимого качества и функциональности?
Читаем внимательно — я говорил о неприятии западной аудиторией идеи «элитарных» пользователей, а не идеи ведения дискуссии!
Как раз наоборот, нормальная культура диспута отсутствует в России.
Кстати, то, что делает Google — это:
1). Совсем другой формат — вместо пользовательского обмена мнениями – обмен мнениями между признанными экспертами, пользователи только голосуют. Но это ведь не то, что хотелось бы, не так ли?
2). Это как раз может сработать (а может и нет), так как Google обладает достаточной известностью, влиянием и деньгами, чтобы приглашать авторитетных экспертов. Но на сайт Вашего проекта они просто не придут, даже если Вы на них выйдите как-то и сможете послать приглашение. Ведь Ваш сайт никому не известен, у него нет аудитории, высоких рейтингов и т. п.
Это и есть проблема начальной раскрутки – для которой нужны деньги на рекламу, в том числе в СМИ. Западных СМИ. Понятное дело, что Google имеет деньги и вообще сам по себе в рекламе уже даже не нуждается.
Как-то это странно — призываете к свободному обмену идеями, кодом и т. п., при этом зарабатываете себе на жизнь работая в компании, где нужно подписывать NDA и не находите в этом противоречия. Если Вы лично не можете заработать себе на жизнь воплощая в жизнь именно такую модель, которую считаете правильной — то может быть все-таки эта модель нежизнеспособна? :)
Какое NDA? Почему вообще сторонники бесплатного и свободного обмена идеями, кодом программ и т. п. без ограничений сами работают на таких работах, где нужно подписывать NDA? Что мешает каждому конкретному человеку, пропагандирующему эти идеи, воплотить их на практике уже сейчас? Что называется — начать с себя. А потом уже заниматься пропагандой, показывая всем свои достижения.
Надеюсь, Вы не будете спорить с тем, что threads стали неотъемлемым атрибутом современного программирования? Хотя бы в виде POSIX threads в unix-подобных системах.
В чем цель моей маленькой статьи? Как можно проще объяснить человеку изучающему системное программирование, но еще не знающему, что такое threads их суть. Не рассказать КАК они реализованы в деталях В ОДНОЙ ЕДИНСТВЕННОЙ системе (ядро которой рассматривает threads как процессы), а объяснить САМО ПОНЯТИЕ.
Что за бессмысленная и беспощадная мода российских форумов — все деструктировать постоянными отрицаниями всего сущего, бесконечно глубокими въедливыми копаниями где чего нет… Не нравится Вам мое определение theads — дайте свое, только универсальное для разных ОС, которое можно было бы применить и к Windows, хотя бы. Нравится она Вам (или мне) или нет — но это самая распространенная система в мире.
Что Вы хотите мне доказать? Что в ядре Linux нет threads в общепринятом смысле слова? Я не собираюсь с этим спорить. Однако threads как способ организации вычислений в программах уже стали классикой абсолютно во всех универсальных ОС, включая Linux. Они есть в Linux в виде POSIX threads и почти все мало-мальски сложные программы их используют. И для прикладного программиста они отличаются от процессов именно тем, что разделяют общее адресное пространство. Именно с учетом этого и таким образом их используют при написании кода. В детали же реализации ядра Linux заглядывают только специалисты по этому самому ядру (и может быть какие-то единичные самые хитро-системные программисты, которым недостаточно POSIX API для работы с threads). Поэтому не вижу никакого смысла бежать от понятия «thread» и бороться со всяким упоминанием этого «крамольного понятия» только на том основании, что в ядре Linux они реализованы как частный случай процессов, разделяющих одно адресное пространство.
На процессор (как и на любое технически сложное устройство) можно смотреть по-разному. Можно с точки зрения пользовательской и тогда threads его прекрасно виртуализируют. Можно с точки зрения специалиста по системному программированию, читающего книги типа «кое-что об устройстве современных процессоров» в трех томах, и тогда не приходится говорить ни о какой виртуализации. :)
Да, не спорю — можно и так, можно сказать, что это контекст исполнения программы. Но хотя с точки зрения абстрактной такое определение будет верным и по-своему красивым, начинающему программисту оно не дает понимания того, что такое threads в обыкновенных современных ОС, как они там работают. У определения через виртуальные процессоры есть все-таки связь с суровой реальностью, данной нам в ощущениях (с устройством ОС) и оно что-то объясняет программисту, который хочет разобраться в реализации threads. Можно понять, что же примерно делается в обыкновенных ОС — что они сохраняют состояние процессора и переключаются между сохраненными состояниями и этим достигают видимости одновременной работы многих процессоров. Ваше определение показывает, как это выглядит в языках полностью абстрагирующихся от железа и вообще от деталей устройства компьютера, но не дает понимания откуда взялись threads на уровне ОС и что же они там-то представляют из себя.
Предлагаю выбрать что-то одно в качестве единицы исполнения (пусть это будет thread), а что-то другое – как контейнер. Пусть это будет процесс. Пусть он имеет свое адресное пространство и объединяет те threads, которые работают в этом адресном пространстве.
Если у нас будет сразу две базисных единицы исполнения (и процесс, и thread), то мы сами себя запутаем.
Можно пойти по другому пути, как в раннем Linux. И thread вообще не вводить как понятие на базисном уровне. Сказать, что это «просто такие особые легковесные процессы». Но threads сейчас используются миллионами программистов по всему миру, в том числе и в Unix (pthreads).
И поэтому все равно придется в современном мире их вводить как понятие на пользовательском уровне. И в ядре тоже есть куча всего, связанного с поддержкой threads – опять-таки, придется их упоминать в коде и в документах для описания соответствующих частей ядра. Смотрим, например, современные исходники ядра Linux. Слов thread встречается более, чем в 2000 файлов!
И чтобы внести ясность логично только thread и оставить в качестве элементарной (а не производной) единицы исполнения. Зачем две разных исполнимых сущности на одном уровне абстракции?
Если мы хотим для себя построить ясную систему понятий, а не просто описать одну любимую исторически сложившуюся ОС, то логично разделить понятия thread и процесса (контейнера, содержащего (в том числе) и threads работающие в одном адресном пространстве).
1. Я не привязан к одной системе, нахожу плюсы как в POSIX API, так и в Win 32 API. Что же касается перевода слова «thread» на русский язык как нить, то это скорее влияние OS/2. Собственно, современные threads пришли к нам всем именно оттуда, из OS/2.
Win 32 API это перефразированный и дополненный API OS/2, а POSIX threads возникли как ответ на OS/2 и Win 32 threads — раньше в Unix не было своих threads ни в каком виде вообще, они полностью продинамили эту идею, но затем наверстали упущенное с помощью pthreads.
2. Что касается взгляда на threads как на абстрактные потоки управления — да, я согласен и с таким подходом тоже, Вы правы. Но в Вашей статье очень много привязки все-таки к конкретным современным ОС, а они все именно виртуализируют процессор. Они и прямо в коде своем программном это делают, и концептуально модель именно такова – виртуализируем процессор. Посмотрите, например, на то, что у них представляет собой даже видимый программе контекст thread.
Нет, это совсем не так, треды в Windows никогда не были «подпоркой».
Они унаследованы ей из OS/2 API, а там они появились как концептуальное решение безусловно гениальных дизайнеров данной ОС, определившей по сути весь дизайн Windows 32 API и повлиявшей на множество других современных систем. Еще раньше в широко распространенных системах с идеей тасков, исполняемых параллельно в одном адресном пространстве, работали на майнфреймах IBM. Возможно, что оттуда и пришла идея threads в OS/2, а затем и в Win32 API и в POSIX threads (интересно, что название внутренней структуры для thread в OS/2 (и Windows) и OS/370+ одинаковое – TCB, хотя бука «T» и имеет разное значение, thread vs task).
Переключение полноценных процессов всегда было очень дорогой операцией и на большинстве процессоров таковой и по сей день и является. Полноценные процессы имеют индивидуальные адресные пространства со своими страничными таблицами и их переключение чистит TLB и вносит кучу прочей сумятицы в деятельность процессора. Это почти полный останов процессора, фактически, ну разве что кэш не чистится (слава Богу). Поэтому и на x86, и на прочих процессорах в архитектуру вносят всякие подпорки, призванные снизить impact от переключения полноценных процессов (адресных пространств). Например, системные станицы на x86 могут быть помечены как глобальные и их дескрипторы не будут вынесены из TLB при смене адресного пространства. Но для юзерских станиц такого решения нет.
Решить проблему может только сильный редизайн железа, который возможен и опробован на тех же мэйнфреймах IBM, у которых процессор может регулярными машинными командами работать сразу со многими (!) адресными пространствами, для чего в ядре процессора аппаратно поддержана соответствующая организация всех системных таблиц управления памятью.
P.S. Нафига они нужны нормальной программе — понятия не имею, наверное только для портации унаследованного кода, как и написано по ссылке которую привел khim.
Это по сути такие же threads, только переключаемые исключительно через обращение к системному вызову, без преемптивной многозадачности, при которой операционная система может прервать выполнение thread по таймеру в любой момент времени (даже вне обращения к syscall).
У fibers есть свои сохраненные значения регистров, они очень похожи по своему поведению на «настоящие» threads. Настолько похожи, что их можно конвертировать в thread вызовом API ConvertFiberToThread. В поздних версиях Windows есть так же вызов, с помощью которого программа может проверить исполняется ли она в контексте «настоящего» thread или в контексте fiber.
Так это как раз следствие того, что с самого начала в Linux не предусмотрели threads и затем их пришлось делать через процессы, разделяющие одно адресное пространство. Однако если операционная система с самого начала проектируется с threads, то там четко есть два разных объекта. Для высокой производительности как раз важно отличать их друг от друга. Даже Linux на самом деле вынужден учитывать особенности threads в планировщике, особенно для SMP, SMT и мультиядерной архитектуры. Формально оформляя threads как процессы, в планировщике они вынуждены признать, что эти процессы особенные, например, у них у всех одно адресное пространство и нужно оптимизировать переключения задач так, чтобы поменьше переключаться между пространствами и не трешить TLB и прочие внутренние буферы процессора.
2. При современном уровне развития технологий даже технически невозможно полностью избавить человечество от потребности в ручном труде, пока что это утопия. Но допустим, что это стало возможным, тогда:
3. Ручной труд просто полностью сменится интеллектуальным трудом, причем по-разному оплачиваемым в зависимости от результатов. Нельзя избавиться от денег или их эквивалента в виде неравного доступа к благам цивилизации. Стремление к превосходству — движущая сила прогресса и если убрать этот фактор, то человечество деградирует. Деградировав, оно не сможет поддерживать функционирование машин, которые его обслуживают. Если же машины будут наделены искусственным интеллектом и смогут поддерживать себя сами без помощи людей, то отпадет не только необходимость в деньгах и труде у людей, но и потребность в существовании людей на данной планете. :)
2. Вообще-то прослушивание со стороны американских спецслужб – это наименьшее из зол, если сравнивать его, например, с подслушиванием российскими спецслужбами. Так как последних интересует отнюдь не только проблема терроризма, но и многое другое… :) Я уж не говорю о потенциальном прослушивании со стороны самого mail.ru, как с ведома, так и без ведома руководства.
3. А есть ли российская альтернатива GIPS сопоставимого качества и функциональности?
Как раз наоборот, нормальная культура диспута отсутствует в России.
Кстати, то, что делает Google — это:
1). Совсем другой формат — вместо пользовательского обмена мнениями – обмен мнениями между признанными экспертами, пользователи только голосуют. Но это ведь не то, что хотелось бы, не так ли?
2). Это как раз может сработать (а может и нет), так как Google обладает достаточной известностью, влиянием и деньгами, чтобы приглашать авторитетных экспертов. Но на сайт Вашего проекта они просто не придут, даже если Вы на них выйдите как-то и сможете послать приглашение. Ведь Ваш сайт никому не известен, у него нет аудитории, высоких рейтингов и т. п.
Это и есть проблема начальной раскрутки – для которой нужны деньги на рекламу, в том числе в СМИ. Западных СМИ. Понятное дело, что Google имеет деньги и вообще сам по себе в рекламе уже даже не нуждается.
В чем цель моей маленькой статьи? Как можно проще объяснить человеку изучающему системное программирование, но еще не знающему, что такое threads их суть. Не рассказать КАК они реализованы в деталях В ОДНОЙ ЕДИНСТВЕННОЙ системе (ядро которой рассматривает threads как процессы), а объяснить САМО ПОНЯТИЕ.
Что за бессмысленная и беспощадная мода российских форумов — все деструктировать постоянными отрицаниями всего сущего, бесконечно глубокими въедливыми копаниями где чего нет… Не нравится Вам мое определение theads — дайте свое, только универсальное для разных ОС, которое можно было бы применить и к Windows, хотя бы. Нравится она Вам (или мне) или нет — но это самая распространенная система в мире.
Если у нас будет сразу две базисных единицы исполнения (и процесс, и thread), то мы сами себя запутаем.
Можно пойти по другому пути, как в раннем Linux. И thread вообще не вводить как понятие на базисном уровне. Сказать, что это «просто такие особые легковесные процессы». Но threads сейчас используются миллионами программистов по всему миру, в том числе и в Unix (pthreads).
И поэтому все равно придется в современном мире их вводить как понятие на пользовательском уровне. И в ядре тоже есть куча всего, связанного с поддержкой threads – опять-таки, придется их упоминать в коде и в документах для описания соответствующих частей ядра. Смотрим, например, современные исходники ядра Linux. Слов thread встречается более, чем в 2000 файлов!
И чтобы внести ясность логично только thread и оставить в качестве элементарной (а не производной) единицы исполнения. Зачем две разных исполнимых сущности на одном уровне абстракции?
Если мы хотим для себя построить ясную систему понятий, а не просто описать одну любимую исторически сложившуюся ОС, то логично разделить понятия thread и процесса (контейнера, содержащего (в том числе) и threads работающие в одном адресном пространстве).
Win 32 API это перефразированный и дополненный API OS/2, а POSIX threads возникли как ответ на OS/2 и Win 32 threads — раньше в Unix не было своих threads ни в каком виде вообще, они полностью продинамили эту идею, но затем наверстали упущенное с помощью pthreads.
2. Что касается взгляда на threads как на абстрактные потоки управления — да, я согласен и с таким подходом тоже, Вы правы. Но в Вашей статье очень много привязки все-таки к конкретным современным ОС, а они все именно виртуализируют процессор. Они и прямо в коде своем программном это делают, и концептуально модель именно такова – виртуализируем процессор. Посмотрите, например, на то, что у них представляет собой даже видимый программе контекст thread.
Они унаследованы ей из OS/2 API, а там они появились как концептуальное решение безусловно гениальных дизайнеров данной ОС, определившей по сути весь дизайн Windows 32 API и повлиявшей на множество других современных систем. Еще раньше в широко распространенных системах с идеей тасков, исполняемых параллельно в одном адресном пространстве, работали на майнфреймах IBM. Возможно, что оттуда и пришла идея threads в OS/2, а затем и в Win32 API и в POSIX threads (интересно, что название внутренней структуры для thread в OS/2 (и Windows) и OS/370+ одинаковое – TCB, хотя бука «T» и имеет разное значение, thread vs task).
Переключение полноценных процессов всегда было очень дорогой операцией и на большинстве процессоров таковой и по сей день и является. Полноценные процессы имеют индивидуальные адресные пространства со своими страничными таблицами и их переключение чистит TLB и вносит кучу прочей сумятицы в деятельность процессора. Это почти полный останов процессора, фактически, ну разве что кэш не чистится (слава Богу). Поэтому и на x86, и на прочих процессорах в архитектуру вносят всякие подпорки, призванные снизить impact от переключения полноценных процессов (адресных пространств). Например, системные станицы на x86 могут быть помечены как глобальные и их дескрипторы не будут вынесены из TLB при смене адресного пространства. Но для юзерских станиц такого решения нет.
Решить проблему может только сильный редизайн железа, который возможен и опробован на тех же мэйнфреймах IBM, у которых процессор может регулярными машинными командами работать сразу со многими (!) адресными пространствами, для чего в ядре процессора аппаратно поддержана соответствующая организация всех системных таблиц управления памятью.
У fibers есть свои сохраненные значения регистров, они очень похожи по своему поведению на «настоящие» threads. Настолько похожи, что их можно конвертировать в thread вызовом API ConvertFiberToThread. В поздних версиях Windows есть так же вызов, с помощью которого программа может проверить исполняется ли она в контексте «настоящего» thread или в контексте fiber.