Уважаемый mayton,
mayton9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).Ссылку на статью укажите пожалуста.

maytonПривет друзья.

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

Некоторые поинты:

1) Отказ от программирования потока Thread как от единицы параллелизма в бизнес приложениях. Предполагается что event-driven более эффектичен чем масоовые "сидения" потоков в "мониторах".
2) Использование асинхронного вызова (async-call, callable, future, promise) в тех случаях когда это возможно.
3) Пересмотр архитектуры Thread с использованием Fiber (пример project Loom). Кооперативность снова в деле. Continuations (под другим названием).
4) Использование актора (обычно в совокупности с очередями и легковесными потоками). (Akka). Неблокирующие операции. Дешевизна ресурсов. Один нативный поток ОС обслуживает сотни акторов.
5) Использование корутины (coroutines). Использование уступчивого return (yield) (C#,Python) для организации сложных итераторов и генераторов.
6) Функциональный подход в части декомпозиции циклов (for-while) в рекурсии (Erlang) где это (теоретически)
даёт возможность гибкого управления кооперативной мультипоточности.
7) Последние экономические тренды в области строительства ЦОД. Отказ от покупки крупных серверов и предпочтение
облаков. Микросервисы.
8) Специальные языки где асинхронный I/O выдвинут как feature (Node.JS). Языки - где корутина - фича. Go(goroutine).
9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).

Пруфы приводить не буду. Топик - просто является неким облаком тегов или смыслов которые я предлагаю обсудить.
Если я где-то ошибся - и классифицировал понятия не так - прошу прощения. Я также мог ошибится в связи ЯП и фич. Sorry.
Но надеюсь общий смысл будет ясен.

P.S. Убежден что поток как единица разработки совершенно необходим в вычислительных задачах с HighLoad-CPU
нагрузкой. Особенно где длительное время нет взаимодействия с внешним миром. Есть только взаимодействие АЛУ и memory
канала. Но такие задачи достаточно специфичны и в бизнес-приложениях их не много.

Какова будет мультипоточность в будущем?

Прошу ваши каменты. Должно быть упрощение разработки. Должно быть.
Уважаемый mayton,
надо рассматривать три взаимосвязанные вещи, но которые имеют четкие границы:
1. доменную модель и возможность ( необходимость ) ее распараллеливания. И синхронизацию данных.
2. инструмент для работы: язык, фрамеворк. Позволяет ли. Заложено ли.
3. персонал, который имеет скилсы для решения и использования первых двух.

mayton9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).последний пункт, надо внимательно осилить оригинал статьи без перевода. Могут быть варианты.

maytonКакова будет мультипоточность в будущем?
Прошу ваши каменты. Ваш вопрос, что - уже устарел, ну когда Вы его задавали ?

maytonВы невнимательно читаете первый пост.Уважаемый mayton, что из Вашего первого поста я понял не правильно ?