как может быть основой то

это как раз просто: преобразования галилея являются частным случаем появившихся много позже преобразований лоренца. и таких примеров в математике и физике — пруд пруди.

А если я ложу трубу, занимаюсь делами, а затем звоню в другое время, — это неблокирующая.

В таком случае — да, это неблокирующая синхронная операция и ты изобрёл epoll. Поздравляю.

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

То есть, ты как-бы не заметил, что дейкстра и хоар обосрались?

Вы почти сделали мой день.

Но накал идиотии еще недостаточно высок. Отожгите, пожалуйста, еще. Вы можете, весь LOR ждет от вас большего!

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

Еще раз: Модель Акторов НЕ опиралась НИКОИМ ОБРАЗОМ на работы хоара, и уж тем более, дейкстры. Напротив, она конфликтовала с ними.

изобрёл epoll

это не epoll, а poll

проблемы с распараллеливанием

какие? их уже лет 10 как научились решать

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

Еще раз

Эдсгер Дейкстра разработал семафоры, а позднее, в период между 1971 и 1973 годах, Чарльз Хоар и Пер Хансен для решения проблемы мьютексов разработали мониторы.[14][15][16] Однако, ни одно из этих решений не создавало в языках программирования конструкций, которые бы инкапсулировали доступ к совместным ресурсам.

В переводе, на наш, деревенский, это называется обосрались. В переводе на лор-диалект - ниасилили. Вы можете перевести на свой великий и могучий ЕЗЫК, как посчитаете нужным, меня это не интересует.

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

Да. Бред анонiмуса не читал

Я тебе повторяю, что твой пример никакого отношения к сабжу не имеет.

Вы, кстати, так и не указали источник своей цитаты. Это ваша курсовая работа?

википедия.

мой ответ имеет отношение к комментарию eao197. зачем ты влез сюда со своей когнитивной дисфункцией — вопрос.

а ссылки на оригиналы [Hewitt, Atkinson 1977, 1979] и [Atkinson 1980]).

Я влез, потому что твой ответ не верен. Он был бы верен, если бы модель Акторов испытала влияние дейкстры и хоара. Но этого не было

между прочим, ооп не об этом.

между прочим у тебя каша в голове. пока

википедия.

И почему я не удивлен?

Он был бы верен, если бы модель Акторов испытала влияние дейкстры и хоара. Но этого не было

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

это не epoll, а poll

Да хоть и poll, суть в том, что он отошёл от своих же слов об асинхронности и скатился к синхронным алгоритмам.

их уже лет 10 как научились решать

Но не для принципиально новой параллельности им. анонiмуса.

Вы можете привести пруф, где утверждается обратное. Тогда будет о чем говорить. Я привел это + ссылки на оригинальные работы. Вы кроме пустословия — ничего.

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

и скатился к синхронным алгоритмам.

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

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

Это не так

от своих же слов об асинхронности и скатился к синхронным алгоритмам.

Возможно ты путаешь синхронизацию с синхронностью, я хз.

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

Нет. В асинхронных операциях тебе побоку порядок. В синхронных — сильно не побоку.

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

Нет. Асинхронные неблокирующие — это, например, когда ты шлёшь своему асинхронному актору асинхронное сообщение «X, потом пошли сообщение актору Y». И в этом случае мы получаем callback hell over actors, о котором я уже говорил. А синхронные неблокирующие — poll, цикл, треды руками что ничерта не совпадает с твоими предыдущими словами.

если бы ты начал пользоваться формальной логикой вместо женской, то узнал бы что «необходимо» — это не совсем то же самое что и «равно»

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

Вы можете привести пруф, где утверждается обратное.

В приведенной вами цитате из вики нет доказательства того, что «в реализации параллелизма реально именно модель Акторов послужила основой.» Так что мне не нужно что-либо доказывать. А вот вам свой тезис нужно как-то подтвердить.

anonimous должен умереть.

Уходи.

Есть. Идите по ссылкам, источникам, и изучайте.

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

man event driven, erlang

необходимы ли потоки для параллельного выполнения? нет, не необходимы

вот и всей дискуссии

необходимы ли потоки для параллельного выполнения? нет, не необходимы

Это заразно :/

Это заразно :/

что именно?

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

Открой английскую вики и ещё раз попытайся понять смысл слов parallel и concurrency.

Пока что получается каша. Например, асинхронная работа с сокетами в одном процессе/потоке это конкурентность, но она НЕ параллельна. Тем временем, вычисления числа пи и вычисление ряда Фибоначчи в двух потоках (процессах) на двух и более процессорной системе выполняются одновременно (паралелльно).

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

«вот это вот все» (с)

Безумие.

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

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

man конечные автоматы что ли?

man конечные автоматы что ли?

А при чем тут они?

Ядро может предоставлять API и само делать потоки. Другое дело что юзерспейс должен быть в курсе этого и быть как минимум thread-safe.

я занимаюсь безумием в рамках ежедневной рабочей деятельности

у тебя все на процессах?

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

Я не в теме, но действительно, зачем мьютекс, если, например, в Plan 9 и Inferfno всё рулится каналами (между корутинами) и пламбингом (между процессами)?

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

Разделяемая память

Фишка потоков в том, что они работают в одном адресном пространстве, что порой решает при обработке, например, смапанного в память файла. У процессов copy-on-write. И коммуникация между процессами дороже, чем между потоками

Непосредственный доступ к памяти быстрее каналов. Иногда это важно.

Ну расскажи уже, интересно же.