LINUX.ORG.RU

нужны ли потоки?

 , ,


0

1

Раньше я как-то неправильно представлял себе абстракции параллельного выполнения. Я думал как-то так: либо у нас есть абстракция потока, либо есть акторы, которые инкапсулируют потоки. Таким образом, нам сначала нужны, например, сопрограммы, которые будут реализовывать потоки, затем уже все остальное поверх этого.

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

Чтобы иметь конкурентность, потоки вообще не нужны. И легкие нити тоже не нужны. Нам просто надо убрать, по возможности, все блокирующие операции. Если мы это сделаем, у нас уже будет конкурентное исполнение. Уже поверх этого мы можем реализовать синхронизацию событий, и тогда у нас родится абстракция потока. То есть все наоборот — сначала конкурентность, а уже поверх нее потоки. В итоге, в одном единственном ивентлупе мы имем 100-процентный параллелизм, полную абстрагированность от порядка выполнения.

Кто ходит в гости по утрам...

erfea ★★★★★
()

ооп тоже не нужно. и даже ф-ии не нужны. нужно просто что б глобальные переменные никто не трогал, кроме тех кто должен. всё просто жи!!!111 хахахаха!!!

anonymous
()
Ответ на: комментарий от anonymous

нужно просто что б глобальные переменные никто не трогал, кроме тех кто должен. всё просто жи!!!111 хахахаха!!!

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

ambiguousnick
() автор топика

Сделай proof-of-concept вычислительную систему такого плана, потом поговорим.

Deleted
()

Чтобы иметь конкурентность, потоки вообще не нужны. И легкие нити тоже не нужны.

man IOCP и у тебя всё будет ОК с потоками и прочим.

Потоки и прочее нужны хотя бы потому, что иначе тебе нужна будет своя ОС, не?

Нам просто надо убрать, по возможности, все блокирующие операции.

И что будет вместо них? У тебя есть сокет, как ты собираешься отреагировать на пришедшее оттуда сообщение?

x3al ★★★★★
()
Ответ на: комментарий от x3al

У тебя есть сокет, как ты собираешься отреагировать на пришедшее оттуда сообщение?

сокет, допустим, это актор. когда он получает сообщение, он уведомляет получателя. Получатель, соответственно, реагирует.

ambiguousnick
() автор топика
Ответ на: комментарий от ambiguousnick

Еще один аккаунт анонимуса.

Я пока себе это смутно представляю. Это должен быть другой слой абстракции, я думаю.

Вот в этом весь anonimous

anonimous: Я тут понял, что %technology-name% (не нужно)/(идеологически неправильно) надо это непременно устанить.
первый же оппонент: Это весьма удобная технология, которую придумали потому, что без нее было хуже. Что более хорошее ты предлагаешь взамен?
anonimous: Я пока себе это смутно представляю

Aswed ★★★★★
()
Ответ на: комментарий от ambiguousnick

сокет, допустим, это актор. когда он получает сообщение, он уведомляет получателя. Получатель, соответственно, реагирует.

Что происходит когда пока получатель обрабатывает сообщение, поступает ещё одно?

x3al ★★★★★
()
Ответ на: комментарий от ambiguousnick

А в чем тогда смысл? Убираем одну абстракцию и меняем ее на другую? У вас отличные задатки грантососа.

Deleted
()
Ответ на: комментарий от x3al

Что происходит когда пока получатель обрабатывает сообщение, поступает ещё одно?

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

ambiguousnick
() автор топика

Что останется когда ты уберёшь все блокирующие операции? Ответ - ничего, но работать всё будет очень очень быстро.

ya-betmen ★★★★★
()
Ответ на: комментарий от ambiguousnick

И куда попадает второе сообщение? В очередь? Или запускается ещё один актор?

Напоминаю на всякий случай: в распространённых ОС нет «акторов». Есть «треды». Если ты не настолько свихнулся, чтобы предлагать новую ОС, то всё это будет поверх тех же тредов.

x3al ★★★★★
()

Чтобы иметь конкурентность, потоки вообще не нужны.

Так и есть.

А разве они действуют в разных потоках? нет. все просто происходит одновременно.

Одновременно в разных потоках.

У тебя какие-то когнитивные аномалии.

anonymous
()
Ответ на: комментарий от anonymous

в разных вычислителях, которые не обязаны быть обёрнуты в какие-то дополнительные абстракции вроде потоков :)

anonymous
()
Ответ на: комментарий от anonymous

я понял что имеет в виду анонiмус, как обычно ерунда

anonymous
()
Ответ на: комментарий от ambiguousnick

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

А такая теория уже появилась?

Есть развиваемая Хьюитом модель акторов, но на изыскания данного товарища на практике все кладут большой болт. Теория акторов — это что-то новое. Или вы так тонко над Хьюитом постебались?

eao197 ★★★★★
()
Ответ на: комментарий от x3al

железки — легко: arm, x86...

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

anonymous
()
Ответ на: комментарий от anonymous

Да нифига они ничего не требуют: в оффтопике есть IOCP, довольно близкое к тому, что ТС хочет (учитывая, что он сам не понимает, что хочет), причём там всё это будет завёрнуто именно в потоки, а не процессы, а всякие concurrent dos на современном железе бесполезны.

x3al ★★★★★
()
Ответ на: комментарий от eao197

анонiмус, видимо, имел в виду пи-исчисление. но в виду тотальной безграмотности...

anonymous
()
Ответ на: комментарий от x3al

Да нифига они ничего не требуют

как иначе разграничивать права доступа?

в оффтопике есть IOCP, довольно близкое к тому, что ТС хочет

нет. анонiмус хочет отменить потоки. для этого сначала надо отменить разграничение прав доступа. почему-то по состоянию на сегодня такие ос оказались никому не нужны :)

anonymous
()
Ответ на: комментарий от ya-betmen

Что останется когда ты уберёшь все блокирующие операции? Ответ - ничего, но работать всё будет очень очень быстро.

нет. Фишка в том, что все что мы делаем в коде — это отсылаем асинхронные сообщения, не дожидаясь ответа. То есть, наша программа представляет собой не описание последовательности вычислений, как например в таком вот коде


foo(bar())

foo вызвало bar и ждет ответа, bar производит вычисления, возвращает ответ коллеру и тд. А в нашем случае

[соde]

foo send(bar) отослали запрос и не ждем ответа another другой асинхронный код

...

спустя неопределенное время bar произвел вычисления, и, возможно отправил сообщение, возможно foo, возможно еще кому то. Главное отличие — отсутствие состояния вычисления, отсутствие контрол-флоу. Мы вместо ожидания ответа просто освобождаем управление. А сами вычисления, разумеется, будут потреблять процессорное время, просто мы никогда не знаем, когда это происходит, и в какой последовательности. У нас нет состояния вычисления, только конфигурация — описание того, как объекты реагируют на сообщения.

ambiguousnick
() автор топика
Ответ на: комментарий от eao197

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

ambiguousnick
() автор топика
Ответ на: комментарий от ambiguousnick

вот до чего доходит человек когда не решает реальных проблем

anonymous
()
Ответ на: комментарий от ambiguousnick

При чём тут асинхронные сообщения, ты же говорил про убирание блокирующих операций.

Ты предлагаешь принципиально новую ОС что ли?

ya-betmen ★★★★★
()
Ответ на: комментарий от ambiguousnick

А в реализации параллелизма реально именно модель Акторов послужила основой.

Глупость какая.

anonymous
()
Ответ на: комментарий от ambiguousnick

foo send(bar) отослали запрос

Возможно, Вы имели в виду: foo(await bar). Но это давным-давно реализовано

и не ждем ответа another другой асинхронный код

Ты хочешь странного, но это и сейчас можно.

Вопрос остаётся в силе: когда нужно задействовать ещё одно ядро вполне конкретного CPU, а когда запихнуть сообщение в очередь до тех пор, пока не освободится обработчик.

x3al ★★★★★
()
Ответ на: комментарий от ya-betmen

При чём тут асинхронные сообщения, ты же говорил про убирание блокирующих операций.

это и есть убирание блокирующих операций. любое асинхронное сообщение — это неблокирующая операция. Если у нас синхронных сообщений нет, значит и блокирующих операций нет в основе.

ambiguousnick
() автор топика
Ответ на: комментарий от x3al

Но это давным-давно реализовано

какая разница, он код всё равно не пишет, просто теоретизирует

anonymous
()
Ответ на: комментарий от ambiguousnick

блокирующих операций нет в основе

маня-мирок

anonymous
()
Ответ на: комментарий от ambiguousnick

Как именно ты реализуешь банальный mutex поверх всего этого? Вариант «он не нужен» не принимается.

x3al ★★★★★
()
Ответ на: комментарий от x3al

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

ambiguousnick
() автор топика
Ответ на: комментарий от ambiguousnick

А отсылка асинхронного сообщения у тебя тоже неблокирующая операция? А приём?

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

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

как у тебя без потоков будет происходить параллельное выполнение?

А помощью асинхронности!

anonymous
()
Ответ на: комментарий от ambiguousnick

А в реализации параллелизма реально именно модель Акторов послужила основой.

Какого параллелизма?

И таки вы говорили о модели акторов или о какой-то теории акторов?

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от ambiguousnick

Окей, вывод: ты хочешь Haskell с сахаром вокруг IOCP.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Как именно ты реализуешь банальный mutex поверх всего этого? Вариант «он не нужен» не принимается.

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

ambiguousnick
() автор топика
Ответ на: комментарий от eao197

Какого параллелизма?

Всякого

В начале 1960-х прерывания стали использовать для имитации одновременного выполнения нескольких программ на одном процессоре.[13] Наличие параллелизма с общей памятью привело к проблеме управления параллелизмом. Первоначально эта задача задумывалась как один из мьютексов на отдельном компьютере. Эдсгер Дейкстра разработал семафоры, а позднее, в период между 1971 и 1973 годах, Чарльз Хоар и Пер Хансен для решения проблемы мьютексов разработали мониторы.[14][15][16] Однако, ни одно из этих решений не создавало в языках программирования конструкций, которые бы инкапсулировали доступ к совместным ресурсам. Инкапсуляцию сделали позже Хьюитт и Аткинсон, построив параллельно-последовательный преобразователь ([Hewitt, Atkinson 1977, 1979] и [Atkinson 1980]).

ambiguousnick
() автор топика
Ответ на: комментарий от ambiguousnick

В таком случае отправка/приём сообщения == блокирующая операция без всяких «но» и твоя модель не работает.

x3al ★★★★★
()
Ответ на: комментарий от Deleted

Это очень, ОЧЕНЬ быстро работает, если посмотреть на тот же PyParallel.

x3al ★★★★★
()
Ответ на: комментарий от ambiguousnick

Во-первых, откуда цитата?

Во-вторых, как может быть основой то, что появилось уже после достижений Дейкстры и Хоара?

eao197 ★★★★★
()
Ответ на: комментарий от x3al

В таком случае отправка/приём сообщения == блокирующая операция

Допустим, я звоню в техподдержку сотового оператора. А там отвечает только один сотрудник. Сотрудник (ресурс) занят. Меня вешают на ожидание, врубают музычку. Если я жду ответа — это блокирующая операция. А если я ложу трубу, занимаюсь делами, а затем звоню в другое время, — это неблокирующая. Я могу так дозваниваться хоть тысячу лет, похрену. Но *концептуально* и в том и в другом случае я *жду освобождения ресурса*. Еще проще, если там стоит автоответчик, и сообщает, что когда оператор освободится, он сам перезвонит.

ambiguousnick
() автор топика

нужны ли:

форумы, пользователи, темы, посты, мысли, предложения, буквы, информация ...

зачем вилки, ложки, если можно руками или без ...

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

зачем транспорт, если можно дойти пешком или зачем пешком если есть транспорт ...

anonymous
()
Ответ на: комментарий от eao197

что появилось уже после достижений Дейкстры и Хоара?

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

ambiguousnick
() автор топика
Ответ на: комментарий от ambiguousnick

еще забыл упомянуть вариант - просто меняю оператора или составляю претензию

anonymous
()
Ответ на: комментарий от ya-betmen

А отсылка асинхронного сообщения у тебя тоже неблокирующая операция? А приём?

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

ambiguousnick
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.