AddxОсновная проблема многопоточности - это зависимости и блокировки. Ошибки (не только баги, но и просчеты в архитектуре) тут очень дороги, а ловить их сложнее. Поэтому ставится задача как-то упростить многопоточные неблокируемые операции, встроить в язык.
Я не исключаю, что определенная реализация сложной многопоточности появится в железе с соответствующей поддержкой в языках.
Уже сейчас есть НТ, AVX, OpenCL, но они сильно специализированы.
"Основная проблема многопоточности" в следующем:
Компьютер выполняет только ОДНУ программу за раз. Точка. (конечный автомат)
Программа может быть ЗАГРУЖЕНА В ПАМЯТЬ параллельно с другой, но выполняться будет только одна.
Можно переключаться между ними, но тогда это роняет безопасность, т.к. никакой защиты нету.

В наши дни программы имеют сотни и тысячи инструкций, что нагружает то самое "бутылочное горлышко" в процессоре - блок разбора инструкций, куда они попадают в первую очередь.
И чтобы компьютер не простаивал, а был занят делом постоянно, нужно держать в памяти более 1й программы (этим уже занимается ОС). Тут встаёт вопрос об эффективном распределении ресурсов.
Потом появилась идея "а почему бы нам не воткнуть более 1го процессора в систему?" - и вот отсюда пошли проблемы с параллельным программированием (параллелизмом)...
У всех процессоров одно и тоже адресное пространство, что означает: каждый процессор может получить доступ к любому биту памяти. Т.е. память ПОЛНОСТЬЮ доступна всем процессорам одинаково.
Отсюда растут ноги у всех видов overheads и bottlenecks - попытки решить эти проблемы с эффективным управлением этими процессорами.

А самый п....ц наступает при слове "threads". Несколько потоков внутри одного процесса с пересекающимися адресными пространствами (читай: могут править одну и ту же память)...
И что тогда делать с планированием? Потоки могут одновременно получить доступ к любому биту, к любой глобальной переменной и как они там будут себя вести - сотрудничать или нет - неизвестно.
А ещё потоки они тяжёлые и ими сложно рулить = много не наделаешь.
Потоки были представлены, в первую очередь, чтобы эффективно юзать мульти-процессорные системы. Но при этом забыли полностью переосмыслить всю проблему, и это её только усугубило.
Расшаривание адресного пространства между процессами это попытка расширить UNIX-модель для решения проблемы.

"If you have to write programms which take advantage of parallelism this is where most of the mistakes are made."
Очень много нюансов надо держать в голове и поэтому легко наделать ошибок.
И ещё больше гемора вылезает, если система real-time. Потому что надо лочить процессы и потоки, разбираться с приоритетами, итд.
А ещё очень сложно дебажить многопоточные программы, в особенности потому, что нельзя получить полной точной репликации пройденного программой пути от одного запуска до другого, потому что они всегда движутся, как timing differences... Короче нет тулзов, чтобы это отследить. Единственное, что можно сделать, это запускать программу в постоянном debug-mode, что есть оверхед.
И ничего не поделаешь с этим. Можно только признать недостатки этой модели и придумать другую...

В общем армии локов это ПЛОХО. Локи это очень ПЛОХО. Гемор это ПЛОХО. И с т.з. ОС локи тоже ПЛОХО, потому что интерфейс, который мы юзаем, это просто набор примитивов, которые не несут сильно много информации для ОС о том, а для чего этот лок. Они никогда не были спроектированы под программы для конечного юзера, они есть низкоуровневые примитивы.
Так что в unix-based-системах бОльшую часть времени мы откатываем назад к pthread -интерфейсам (pthread_mutex) и там старые механизмы, и они конечно не лучше.
Единственная вещь, которая передаётся с помощью mutex это WORD, который из потока ожидает на указанном локе. Can be attached to one specific action on which the threat is waiting.
Но тут опять человечек не сможет разгрести, т.к. придётся оперировать тысячами локов. Это просто невозможно.

fibers + coroutines + promises + future = решение всех проблем за 10% от скорости (которая нужна только Nginx & Co).

Haskell vs C++
Go vs C++

exp98полудух,
У меня 4-х ядерный комп, что дома что на службе. Если запускаю долгий макрос в эселе, то грузится 25% проца. Смотрю в диспетчере - работают преимущественно 1-2 ядра. Чессгря, не знаю мож и одна только команда способна выполниться одномоментно, а мож и нет.
Только, когда я работал не на персоналках, у нас были по-настоящему многопроцессорные компы, полностью синхронные, с неск арифметиками и неск доступами в память (правда не к одному адресу).
ну так:
полудух1. говоря об асинхронной многопоточности подразумеваем Linux/Unix;
microsoft же - синоним "как из мухи сделать 50-этажного слона"
авторПредыдущий оратор, который убеждал нас пользоваться библиотекой Microsoft Foundation Class (MFC), сказал нам, что поддержка OLE в MFC "включает 20000 строк кода, _необходимых_ для
каждого базового приложения OLE 2.0". Аудитория была ошеломлена не полезностью MFC, а тем фактом, что для написания базового приложения OLE 2.0 требуется 20000 строк кода.

Basil A. SidorovP.S.
Посмотрел гитхаб с асинхронной обработкой http-запроса в хаскеле и так и не понял, почему эта кучка кода проще двух строчек асинхронных ява-сервлетов.
зацените, как ява любит память ...

[quote Siemargl]полудухпропущено...

microsoft же - синоним "как из мухи сделать 50-этажного слона"
нет там нихрена. Всё либо эмуляция, либо маркетинг.
армия индусов не способна написать ничего качественного

Leonid KudryavtsevТ.ч. сама проблема и термин "будущая мультипоточность" лично мне не так очевидна и не очень понятна. Мультипоточность где и для чего? И что этой мультипоточностью хотят достигнуть.
полудух

эта проблема встречается в любых задачах.

зы: много воды льёте

на тестах что-то не видно "полностью угробленной скорости доступа к RAM" )
чтобы не проседать надо не перегружать L1/L2 cache - в нём вся скорость
т.е. всякие инлайны не собирать в цикле, например