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
канала. Но такие задачи достаточно специфичны и в бизнес-приложениях их не много.

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

Прошу ваши каменты.

ИМХО, вопросы производительности и оптимизации часто встают не там, где это нужно.
Люди читают о том, как решить проблему 100500+ rps, а по факту у них там и нагрузки-то такой нет.
А есть совсем в других местах.
Но делаем тут, потому как у Google была тут проблема и они ее решили так.
Или доклад с конференции прочитали.
К вопросу о "С++ быстрее" и прочих "давай померяемся".
Это интересно и важно, но есть два фактора:
1. в 95% приложений абсолютно не нужно. Нет, если вы графический движок, или универсальный сервер пишете ...
2. На производительность часто влияют другие факторы. Реальный код не висит в воздухе, как тесты и примеры.
3. Цифры 5-10-15% вообще ни о чем для не глубоко системного ПО. Завтра оптимизируют компилятор/библиотеки/процессор и будет все наоборот.
Основная проблема многопоточности - это зависимости и блокировки. Ошибки (не только баги, но и просчеты в архитектуре) тут очень дороги, а ловить их сложнее. Поэтому ставится задача как-то упростить многопоточные неблокируемые операции, встроить в язык.
Я не исключаю, что определенная реализация сложной многопоточности появится в железе с соответствующей поддержкой в языках.
Уже сейчас есть НТ, AVX, OpenCL, но они сильно специализированы.