Миф: как IBM победил БЭСМ

[Palych]

zVlad, по-моему Вы что-то путаете.
Threads работают без аппаратной поддержки где угодно.
Это всего лишь абстракция...

[Dmitry67]

Сорри, zVlad, прочтите что такое threads

[zVlad]

A threads в ПС и Юникс серверах это не прогресc, а способ затыкание некоторых дыр в архитектуре. Дыр, которых не было и нет у МФ, и возможно на VAX (последние я не знаю толком, поэтому лишь предполагаю).

А о каких дырах идет речь, уточните, если не сложно?

Присоединяюсь к вопросу

Отсутствие threads приводило к тому что аппликации не могли перерисовывать экран в то время как они думали. Этот эффект был виден воочию на DECwindows, ну и разумеется все на Windows тоже прекрасно помнят такие программы на Windows 3.11, 95 и даже позже.

Сейчас, конечно, zVlad скажет что это не нужно (ну раз не было на IBM). Конечно, для алфавитно цифровых терминалов не нужно было
А для нормальной нужно.
А сейчас threads на z/OS конечно есть, в виртуалках

P.S.
Кстати меня всегда интересовал вопрос, является ли стандартный подход к перерисовке, основанный на threads, правильным в глобальном смысле. То есть чисто экономически это всегда делается так, но манипулирование всеми этими thread safe объектами это ходьба по минному полю, как голые malloc/free. Если запускать спутник, вероятно лучше набор "больших" процессов, обменивающихся сообщениями? С другой стороны я смотрю, threads вроде даже в Ada добавили...

Мой ответ будет краток (на самом деле я тайпал длинный ответ но, либо я что-то нажал не то на моем лаптопе, либо "Привет" глюкнул, и, как это не редко бывает мой текст пропал, а переписывать я не люблю) и этот ответ состоит из одного ключевого слова - "GDDM" наберите его в Google и Вы все сами поймете.

Для тех кому лень делать поиск и читать я скажу что 3270 - это вовсе не только алфавитно-цифровой терминал, это семейство терминалов в котором были и графические устройства до того как появились ПК. Тем неменне я вовсе не считаю что надо делать здесь "back in USSR" и возвращаться к семейству 3270, но знать это надo всем кто хочет считаться грамотными специалистами по компютерам. И еще хороше бы знать что IBM придумали IBM PC как устройство эмулирующeе терминалы 3270 - все семейство, а не только алфавитно-цифровой вариант о котором только и знают выходцы из СССР, вроде тебя, Дима. Но получилось иначе... так уж получилось.

[zVlad]

zVlad, по-моему Вы что-то путаете.
Threads работают без аппаратной поддержки где угодно.
Это всего лишь абстракция...

А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?

[zVlad]

Сорри, zVlad, прочтите что такое threads

Дайте Вашу любимую ссылку - с удовольствием еще раз почитаю. Только не уверен что я узнаю что-то новое,но если узнаю обязательно Вам расскажу. OK?

[Palych]

zVlad, по-моему Вы что-то путаете.
Threads работают без аппаратной поддержки где угодно.
Это всего лишь абстракция...

А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?

Потому что это слово многозначное.

[zVlad]

zVlad, по-моему Вы что-то путаете.
Threads работают без аппаратной поддержки где угодно.
Это всего лишь абстракция...

А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?

Потому что это слово многозначное.

Я привык к однозначным определениям. Многозначные я называю - лукавство, до тех пор пока мне не дадут однозначное определение.

[tengiz]

Это swaping, или вытиснение задач называется. Для MF это, скажем так, легкая операция, раз-два и сделали, а вот для Intel и RISC архитектур это всегда была и видимо есть тяжелая операция. Вот и придумали threads - хардверную поддрежку.

Я понял, что Вы имеете в виду. Я не уверен насчет конкретных процессоров, попадающих в категорию RISC, но для продукции Sun и для популярных ОС, работающих на интеле начиная с 386, такой проблемы нет. Переключение между "процессами" и "потоками" (или "нитями" или "легкими процессами") стоит примерно одинаково. Нужно, правда, иметь в виду, что в разных ОС смысл этих слов немного отличается, поэтому может быть путаница. Также у интел имеются аппаратные "недопотоки" (хотя называются они hyperthreads) причина появления которых - недозагруженность конвейеров физических процессоров (а теперь - ядер), при этом при подходящей загрузке это действительно дает выйгрыш. Но это не имело отношения к тяжести переключения "процессов" против переключения "потоков".

Чтобы еще усложнить дело, есть также "легкие потоки", в разных ОС называемые по-разному ("волокна"-fibers, user-more threads, etc.), вот они в чистом виде являются софтверными сущностями, которые не требуют особой аппаратной поддержки и действительно могут переключаться намного дешевле, чем настоящие "потоки" или "процессы" и единственная причина их существования - это избежать дорогого переключения между "настоящими потоками" внутри одного "процесса", однако программировать на них намного сложнее, чем на "настоящих потоках". Но если это делать с умом, выйгрыш по производительности можно получить очень даже материальный.

[Dmitry67]

Да, согласен, действительно слово столь многозначное что мы говорили о разных вещах.

Кстати, когда то попробовал в ms sql "fibers". Разницы не почувствовал, разве что перестали работать distributed transactions

[StrangerR]

Threads это как демократия: ужасная вещь, но к сожалению пока незаменимая.
Хотя попытки предпринимаются...

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

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

[Medium-rare]

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

Ежедневно мутя с потоками, такая радость, их заменить на процессы с общей памятью, не так просто приходит в голову. Лучше сразу убиццо апстену. Деформация такая. Тупеем потихоньку.

[Dmitry67]

Ну вот Оракл по моему написан большими процессами с общей памятью. Но на запуск большого процесса overhead больше

[tengiz]

Кстати, когда то попробовал в ms sql "fibers". Разницы не почувствовал, разве что перестали работать distributed transactions

Это потому, что во-первых, MS SQL и так работал с "настоящими" threads, как если бы они были почти "fibers", во-вторых, они имеют смысл для очень высокопроизводительных сценариев (много процессоров, много их утилизации). Ну и таки да, ошибки были - и в MS SQL и в библиотеке файберов в ОС.

[tengiz]

Ну вот Оракл по моему написан большими процессами с общей памятью.

Это уже давно не совсем так у Оракла.

[Dmitry67]

Угу, но начинали они по моему с этого.