Может какие фундаментальные проблеммы останавливают?
— Ответственность за выделенные ресурсы
— Проблемма остановки
— Общения потоков (mpi, примитивы синхронизации, общие ресурсы)
— Реакция на ошибки
— Усложнение кода
— Ограничения языка
— Ограничения операционной системы
— Сложность вопроса в целом
— Еще что-то

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

Из разряда:
Было 13 стандартов.
Непорядок надо придумать общий.
Стало 14 стандартов.
Оно нам надо?

Есть у кого какие мысли по поводу реализации многопоточности.
Что бы было просто, логично, удобно и красиво.

Здравствуйте, kov_serg, Вы писали:

_>Чего не хватает для нормальной многопоточности.

_>проблеммы
_>Проблемма

зачастую — грамотности

_>- Сложность вопроса в целом

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

_>У всех свои грабли и скрытые ужасы.
_>Или принципиально счастья не будет? Из-за накопленого кода. Или всех устраивает, то что есть?

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

_>Что бы было просто, логично, удобно и красиво.

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

Здравствуйте, kov_serg, Вы писали:

_>Может какие фундаментальные проблеммы останавливают?

Дык есть уже, асинхронными акторами зовётся.
Для затравки:
http://joeduffyblog.com/2015/11/19/asynchronous-everything/
Конкретно — глава "The Execution Model", но всю статью тоже стоит прочитать.

Здравствуйте, kov_serg, Вы писали:

_>Что бы было просто, логично, удобно и красиво.

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

Полагаю, ступор, который возникнет у вас на второй части (с хорошим примером), и станет объяснением.

Здравствуйте, kov_serg, Вы писали:

_>У всех разные подходы но стройного и красивого решения не видно.
_>Чего не хватает для нормальной многопоточности.

Однопоточный мозг человека.

Здравствуйте, kov_serg, Вы писали:

_>У всех разные подходы но стройного и красивого решения не видно.

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

Проблема в том, что в низкоуровневых компилируемых языках, типа Си, в рамках современных операционных систем, ее трудно реализовать эффективно. Потому что CSP предлагает плодить маленькие потоки на каждый чих, а это довольно дорого.

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

Здравствуйте, Sinix, Вы писали:

S>http://joeduffyblog.com/2015/11/19/asynchronous-everything/
S>Конкретно — глава "The Execution Model", но всю статью тоже стоит прочитать.

По-моему, тексты в стиле асинхронных калбеков, даже если они приправлены промисами, человеку читать невозможно...

Здравствуйте, Sharov, Вы писали:

_>>У всех разные подходы но стройного и красивого решения не видно.
_>>Чего не хватает для нормальной многопоточности.

S>Однопоточный мозг человека.

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

Pzz>На мой взгляд, многопоточность в стиле CSP вполне себе стройная и красивая. И имеет под собой внятную теоретическую базу.
Я только не понял, почему Тони Хоара прописали в первооснователи.
Задолго до него (кажись, в 1959) статью написал Эдсгер Дейкстра.
Которая даже была переведена у нас: http://archive.is/L34C

Здравствуйте, LaptevVV, Вы писали:

LVV>Я только не понял, почему Тони Хоара прописали в первооснователи.
LVV>Задолго до него (кажись, в 1959) статью написал Эдсгер Дейкстра.
LVV>Которая даже была переведена у нас: http://archive.is/L34C

Архив висит. Видимо, его программисты не читали ни Хоара, ни Дейкстры

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

LVV>>Которая даже была переведена у нас: http://archive.is/L34C
Pzz>Архив висит. Видимо, его программисты не читали ни Хоара, ни Дейкстры
У меня открыт и я просто сейчас перечислю заголовки частей статьи.
Pzz>Я так понимаю, Дейкства изобрел очень простые и базовые вещи, типа семафоров (которые, конечно, тогда не казались ни простыми ни базовыми). Хоар же построил вполне полную теорию, включающую в себя все необходимое. Хоар не изобретатель потоков вообще, он изобретатель научной базы для определенного стиля, в котором можно с этими потоками управляться.
Вот читай:
ВВЕДЕНИЕ

1. ПРИРОДА ПОСЛЕДОВАТЕЛЬНЫХ ПРОЦЕССОВ

2. СЛАБО СВЯЗАННЫЕ ПРОЦЕССЫ
2.1. Простой пример
2.2. Обобщенная задача взаимного исключения
2.3. Пример

3. НОВЫЙ ПОДХОД К ЗАДАЧЕ ВЗАИМНОГ0 ИСКЛЮЧЕНИЯ
3.1. Необходимость в более реалистическом решении
3.2. Синхронизирующие примитивы
3.3. Применение синхронизирующих примитивов к задаче взаимного исключения

4. ОБЩИЙ СЕМАФОР
4.1. Типичное использование общего семафора
4.2. Избыточность общего семафора
4.3. Ограниченный буфер

5. ВЗАИМОДЕЙСТВИЕ ЧЕРЕЗ ПЕРЕМЕННЫЕ СОСТОЯНИЯ
5.1. Пример приоритетного правила
5.2. Пример с диалогами

6. ПРОБЛЕМА ТУПИКОВ
6.1. Алгоритм банкира
6.2. Применение алгоритма банкира

7. ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ

Написано:
PROGRAMMING LANGUAGES.
NATO Advanced Study Institute.
Edited by F.GENUYS
IBM Paris France
1968, Academic Prsss London and New York

Переведено:
ЯЗЫКИ ПРОГРАММИРОВАНИЯ.
Редактор Ф.Женюи.
Перевод с англ В.П.Кузнецова.
Под ред. В.М.Курочкина.
М:."Мир", 1972

Здравствуйте, Pzz, Вы писали:

Pzz>По-моему, тексты в стиле асинхронных калбеков, даже если они приправлены промисами, человеку читать невозможно...
Ну да, для использования требуется поддержка со стороны компилятора.

в шарпе вместо

SomeAsyncCode()
  .ContinueWith(result => 
  {
    return SomeAsyncCode2(result);
  })
  .ContinueWith(result2 => 
  {
    SomeFinalCode(result2);
  });

можно использовать

var result = await SomeAsyncCode();
var result2 = await SomeAsyncCode2(result);

SomeFinalCode(result);

Соответственно, проблем с записью в continuation-passing style нет.

Здравствуйте, kov_serg, Вы писали:

_>Или принципиально счастья не будет? Из-за накопленого кода. Или всех устраивает, то что есть?

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

_>Есть у кого какие мысли по поводу реализации многопоточности.
_>Что бы было просто, логично, удобно и красиво.

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

Итак, мои требования к многопоточности:
1) Гарантия отсутствия race condition, deadlock и livelock на этапе компиляции.
2) Гарантия "симметричности входов и выходов" — не знаю, как умнее сказать, в общем на каждый асинхронный "вход" должен быть один "выход".

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

Ни на одном известном мне существующем языке программирования это реализовать нельзя, может быть можно попробовать допилить напильником Rust, но не уверен. Одним из основных требований к языку является запрет алиасинга в любом виде (ссылки, указатели и т.п.). У каждого объекта в один момент времени есть ровно один владелец.

Основные понятия:
— Процесс. Базовая единица параллелизма. Тело процесса — последовательность операторов. Процессы организованы в дерево. У каждого процесса есть ровно один родительский процесс и может быть несколько дочерних.
— Протокол. Сущность языка, предназначенная для описания взаимодействия между процессами, абстрактный интерфейс. Протокол накладывает ограничения на реализацию кода процесса. Асимметричная штука, как протоколы в Singularity — то, что является с одной стороны входом, с другой стороны является выходом, и наоборот (то есть программный код реализации одного и того же протокола с разных сторон выглядит зеркально отраженным).
— Портал. Составная часть протокола. Является точкой синхронизации двух процессов, в которой оба процесса блокируются и происходит двухсторонний обмен данными. Обмен данными между процессами возможен только через порталы и никаким другим способом. Портал по сути представляет собой два кортежа, описывающие данные, которыми обмениваются два процесса.

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

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

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

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

Какие я вижу преимущества: программисту не надо расставлять никакие локи, и нет дедлоков.
Какие я вижу недостатки: некоторые вещи я сам не пойму, как сделать, и можно ли сделать вообще (например, пул потоков).

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

Здравствуйте, Pzz, Вы писали:

S>>http://joeduffyblog.com/2015/11/19/asynchronous-everything/
S>>Конкретно — глава "The Execution Model", но всю статью тоже стоит прочитать.

Pzz>По-моему, тексты в стиле асинхронных калбеков, даже если они приправлены промисами, человеку читать невозможно...

Так это проблема с текстовым представлением графа переходов, а не с текстом вообще.
Нужно таки средство рисования графов, которое само строит текст.

Здравствуйте, netch80, Вы писали:

Pzz>>По-моему, тексты в стиле асинхронных калбеков, даже если они приправлены промисами, человеку читать невозможно...

N>Так это проблема с текстовым представлением графа переходов, а не с текстом вообще.
N>Нужно таки средство рисования графов, которое само строит текст.

Проблема не в переходах. Проблема в разрыве контекста.

Здравствуйте, Pzz, Вы писали:

Pzz>>>По-моему, тексты в стиле асинхронных калбеков, даже если они приправлены промисами, человеку читать невозможно...

N>>Так это проблема с текстовым представлением графа переходов, а не с текстом вообще.
N>>Нужно таки средство рисования графов, которое само строит текст.

Pzz>Проблема не в переходах. Проблема в разрыве контекста.

А чем этот разрыв контекста принципиальнее такого же разрыва между разными функциями, модулями, старым добрым event-driven GUI?

Здравствуйте, Sharov, Вы писали:

S>Однопоточный мозг человека.

прямо сейчас ты чувствуешь задницей стул, на котором сидишь, но не осознаёшь это

Здравствуйте, LaptevVV, Вы писали:

Pzz>>На мой взгляд, многопоточность в стиле CSP вполне себе стройная и красивая. И имеет под собой внятную теоретическую базу.
LVV>Я только не понял, почему Тони Хоара прописали в первооснователи.
LVV>Задолго до него (кажись, в 1959) статью написал Эдсгер Дейкстра.
LVV>Которая даже была переведена у нас: http://archive.is/L34C

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Sharov, Вы писали:

S>>Однопоточный мозг человека.

BZ>прямо сейчас ты чувствуешь задницей стул, на котором сидишь, но не осознаёшь это

выделил ключевое

Здравствуйте, AlexRK, Вы писали:

ARK>Я тут на досуге придумал некий велосипед с квадратными колесами. Возможно (и наверняка), что все это уже придумано

знаком с flow graph, например в tbb или в виде аддона к cilk? там даже gui для их рисования есть