Нужна ли многопоточность?

я языки высокого уровня не нужны, есть же ассемблер
и математический анализ не нужен, есть же арифметика
и IDE не нужны, есть же редакторы и консолька

Это действительно лишь вброс. В стиле: «языки высокого уровня нужны тем, кто не умеет программировать на ассемблере».

Сразу стоит сказать о вашей аналогии: тут очевидно имеется в виду не распараллеливание по данным (вроде «сборки вертолетов» каждым из потоков), а разного рода event-driven programming, когда

1) либо осуществляется попытка обрабатывать события параллельно, перекладывая значительную часть нашей работы на планировщик потоков, чем значительно упрощая себе жизнь, так как каждый обработчик события суть автономная процедура, плюс мы можем не задумываясь блокироваться на операциях ввода/вывода;

2) либо когда pool'ится куча источников событий, и конечный автомат, реализованный в едином потоке, все разруливает (конечный автомат, потому что это самая разумная реализация такой схемы, хоть и не обязательная).

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

К сожалению, многие API тоже написаны людьми не умеющими программировать конечные автоматы, в частности с применением синхронного ввода-вывода.

Насколько я понимаю, цитата Кокса относится к тому, что достаточно иметь процессы, а треды не нужны.

Т.е. это таки конвейер, где чередуются фазы - те которые не требуют неразделяемых ресурсов и там используется многопоточность, но элементарно, и те где неразделяемые ресурсы требуются но задача выполняется одним потоком. event-driven programming это процесс согласования этих фаз.

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

Я правильно рассуждаю?

По необходимости. Где-то удобнее треды, где-то отдельные процессы.

Основная засада с многопроцессорностью начинается. начинаешь городить IPC между несколькими инстансами сервера, чтобы они нагружали все ядра. Тут можно как раз применить схему - по треду/процессу на ядро а в каждом треде/процессе уже конечный автомат.

Треды действительно не нужны, только для костылей... Вот процессы - нужны.

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

emacs. Вроде у firefox с многопоточностью проблемы. Добавлю ещё claws-mail.

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

А как бы ты ещё стал программировать например параллельную обработку поступающих снаружи данных, если обработка может занимать длительное время, такое что входной буфер может переполниться следующим блоком до того как предыдущий будет обработан? Обойтись без многопоточности можно, как и без любой другой сущности, но нередко обходиться без неё - самый натуральный изврат.

Единственно вменяемый ответ :)

Более-менее понятно расписано здесь: http://ru.wikipedia.org/wiki/Поток_выполнения

Однопоточная нода (node.js) отлично с этим справляется, как я знаю.

Потоковое программирование

Как мне хочется убить того, кто перевел «нить» как «поток», и всех тех, кто использует «поток» вместо «нить».

«нить управления»?

Однопоточная нода (node.js) отлично с этим справляется, как я знаю.

нет http://stackoverflow.com/questions/9546225/nodejs-how-to-create-a-non-blockin...

И к чему это? К тому, что какой-то анонимус can not into callbacks? Или к чему?

Прочитал еще раз. Никаких проблем не вижу - всё решается в рамках однопоточности благодаря многопроцесности.

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

Согласен. Как пример, медиа-транскодинг в реальном времени. Многое с тредами делается проще.

И одной из причин «дрейфа» многих с FreeBSD на Linux было именно отсутствие поддержки native тредов во фре.

По поводу firefox. Когда ты открываешь страницу, то содержимое страницы загружается в фоновом режиме, а иначе вся отрисовка гуишной формы и вся обработка мышки и клавиатуры просто зависнут. 99% - на то, что такая загрузка делается в отдельном потоке (может быть, через пул), 1% - на то, что это делается в отдельном процессе. Процесс можно и запустить, но тогда дорого обходится передача данных между процессами, тогда как можно предполагать, т.е. не наша головная боль, что передача данных между потоками не стоит ничего или почти ничего.

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

В общем, тот иностранец очень сильно вбросил на счет многопоточности.

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

Прошел по ссылке. Слова того иностранного товарища приводятся в разделе про серверный софт. Как всегда, громкие фразы бывают далеки от истины.

BTW, еще один довод «за» треды это то, что переключение контекста между тредами одного процесса «дешевле» обходиться, чем переключение контекста между процессами.

Зависит от системы вообще-то. На оффтопике именно так, как ты сказал - создание процесса значительно дороже потока. В линуксе «потоки» - это наповерку «легковесные» процессы.

В линуксе «потоки» - это наповерку «легковесные» процессы.

Да, я в курсе.

Но есть еще такая штука как кеш. И при переключении тредов в пределах одного процесса, кеш будет работать эффективнее. У тредов ведь общая память.

Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы.

Контрвброс: конечные автоматы нужны тем, кто не осилил полноту по Тьюрингу.

вертолёты

В вертолетах изпользуется event-driven программирование, оно называется real-time.

Многопоточность Multithreading - это слой астракции над конечным автоматом, управляющим выполнением программы, и в конечном итоге реализуется в виде конечного автомата. Слои абстракции не нужны? Тогда и языки высокого уровня не нужны.

Приложение может быть не обязательно единым конечным автоматом. Это набор конечных автоматов, которые в свою очередь могут выполняться параллельно. Известная модель, которую используют уже непонятно сколько лет. Намного проще оценивать работу сложных алгоритмов.

man actors

man actors

No manual entry for actors

Зато есть такое

aur/tractorgen 0.31.7-1 (1)
    Generates tractors

отбой

==> ERROR: tractorgen is not available for the 'x86_64' architecture.

Не ведись ты нак на вбросы. И да, в пртведенной цитате ничего против многопоточности не сказано. Это он вбросил про потоки вообще.

Да можно и без потоков спроектировать неподтормаживающее приложение, но если оно будет достаточно сложное, то и разработка усложнится в разы. И да, там будет твойнеповторимый и велосипедный аналог потоков.

Да там не про многопоточность вообще, там про event-driven против threads. Но вброс классический, из разряда «ненужно".

Вопрос: компьютер с несколькими ядрами в процессоре - несколько конечных автоматов?

Еговполне можно воспринимать как один автомат, тактуется ядра одинаково же.

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

Конечные автоматы нужны тем кто не осилил СМО.

Система массового обслуживания?

Да.

Эрлангисты смотрят на тред как на говно.

Эрлангисты смотрят на тред как на говно.

На тред исполнения?

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

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

А теперь возьмём для примера программу - «мигалку светодиодом» - там есть две переменные, count и light. Каждую секунду count увеличивается на 1 (по сигналу от таймера, например). Когда он достигает 10, то, сбрасывается в 0. Когда происходит сброс, программа меняет состояние light, если он был равен 0, то становится 1, если 1, то становится равным 0. В бесконечном цикле программа проверяет наступление всех условий и соответствующим образом меняет переменные. Здесь есть два конечных автомата. «count» имеет 10 состояний, «light» - 2. Условия перехода между состояниями определи сам.

А теперь возьмём такую же программу, но в виде потоков. Один поток считает до 10 и устанавливает семафор для второго потока. Второй поток ждёт на семафоре и переключает светодиод. Это точно такая же программа на конечных автоматах, как и описанная выше, но использующая абстракцию многопоточности.

Ну конечно, это же всяких сишников тред больше.

На тред исполнения?

В эрланге нет тредов исполнения.

вот если бы в языке Си были coroutine...

есть такое мнение, и оно не ново

В эрланге нет тредов исполнения.

в смысле? ты зелёные потоки за потоки исполнения не считаешь?

Любитель кальки с английского с отсутствием образного мышления детектед.

--- http://swtch.com/~rsc/talks/threads07/ — любопытная статья Расса Кокса.

Любитель кальки

Ути-пути, деточка. Переведи мне термин «fiber».

с отсутствием образного мышления

Ахаха. Перевести «нить» как «поток» мог только ГСМ, которому невежество заменяло и образное мышление, и знание предметной области.

Цитата из той презентации:

Should we use threads or events?

Andrew Birrell: threads.
John Ousterhout: events.
John DeTreville: no.
Rob Pike: yes.

Bell Labs approach: threads and events

Ахаха. Перевести «нить» как «поток» мог только ГСМ, которому невежество заменяло и образное мышление, и знание предметной области.

Но если бы ты ничего не знал об англоязычной терминологии, как бы ты назвал то, что выполняется параллельно? Едва ли бы ты сказал «выполнение в несколько нитей».

Но если бы ты ничего не знал об англоязычной терминологии, как бы ты назвал то, что выполняется параллельно?

Термин «поток» для обозначения нити стал общепринятым после того, как стал стандартным при переводе руководств Microsoft.

Едва ли бы ты сказал «выполнение в несколько нитей».

Я и «в несколько потоков» не сказал бы - слишком сильно «поток» ассоциируется с «поток данных» (от «потокового ввода-вывода» до классификация Флинна). Кстати, в англоязычной литературе была ровно та же проблема, и поэтому там стал общепринятым термин «thread».

Термин «поток» для обозначения нити стал общепринятым после того, как стал стандартным при переводе руководств Microsoft.

Воздержусь от исследования книг 70-80 годов.

Я и «в несколько потоков» не сказал бы - слишком сильно «поток» ассоциируется с «поток данных»

Как и с «потоком команд», впрочем.

Кстати, в англоязычной литературе была ровно та же проблема, и поэтому там стал общепринятым термин «thread».

Ок.

1. не доверяй вике. Она врёт. Я серьёзно.

Алана Кокса

Не особо вдаваясь в теорию, сразу пошёл контраргумент о многоядерных машинах.

не было у него многоядерной машины. И даже многопроцессорной. Они тогда только у некоторых военов были, и причём постоянно загружены на 146%.

А то и вообще многоядерные машины не нужны

военам нужны. А ты кушай, что дают.

Есть вопросы по теории конечных автоматов. Прочитав статью на википедии суть особо не чувствую

вот уж вправду: лучше уж бы на ЛОРе спросил.

Вообще говоря, конечные автоматы никак не относятся к многопоточности. А фразу Кокса ты неправильно понимаешь, в многопоточном программировании, по мнению Алана, нет места быдлокодерам, неосилившим конечный автомат.

Мнение устарело, ИМХО.

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

бред. Многопоточность == несколько взаимодействующих КА.

На уровне клиентского приложения? Как?