полудух "Основная проблема многопоточности" в следующем:
Компьютер выполняет только ОДНУ программу за раз. Точка. (конечный автомат)

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

полудухПрограмма может быть ЗАГРУЖЕНА В ПАМЯТЬ параллельно с другой, но выполняться будет только одна.


Даже команды одного потока могут исполняться параллельно. Спекулятивное исполнение называется.
Что уж говорить о процессах, которые иногда не просто исполняются параллельно, а и аппаратные ресурсы (память, диск, видеокарта) используют также параллельно.

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

В наши дни программы имеют сотни и тысячи инструкций, что нагружает то самое "бутылочное горлышко" в процессоре - блок разбора инструкций, куда они попадают в первую очередь.
И чтобы компьютер не простаивал, а был занят делом постоянно, нужно держать в памяти более 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, что есть оверхед.
И ничего не поделаешь с этим. Можно только признать недостатки этой модели и придумать другую...


У Вас сплошная путаница. Перемешаны вопросы архитектуры железа, ОС, алгоритмов.
В процессоре нет "бутылочных горлышек". Есть менее используемые блоки, есть более.
Например блок работы с AVX инструкциями обычно "менее загружен".
К любому биту получить доступ нельзя, есть защита памяти. Аппаратная, кстати, дополнительных ресурсов на проверки выделять не нужно. Каждому процессу доступна только своя память. Внутри же процесса проблема "thread safe" решается стандартными способами, не нужно изобретать велосипеды.
Активно взаимодействующие потоки даже на разных ядрах общаются через очень быстрый кэш, не залезая в память, абсолютно прозрачно для них.
А конкретная реализация потоков - это не проблема компьютера или процессора, это проблема ОС. И в целом она вполне справляется. Не во всех сценариях, но все же.

полудухВ общем армии локов это ПЛОХО. Локи это очень ПЛОХО. Гемор это ПЛОХО. И с т.з. ОС локи тоже ПЛОХО, потому что интерфейс, который мы юзаем, это просто набор примитивов, которые не несут сильно много информации для ОС о том, а для чего этот лок. Они никогда не были спроектированы под программы для конечного юзера, они есть низкоуровневые примитивы.


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

полудухТак что в 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).

Часто локов можно избежать на архитектурном уровне при построении приложения. Я хотел сказать именно об этом.
А "решение всех проблем" - это, скажем так, слишком смелое заявление.

полудухне у меня, а у человека, который пишет компиляторы и на ночь читает чертежи процессоров.
Ulrich Drepper зовут.
но у вас конечно аппаратура лучше


Всегда удивляли люди, которые говорят от имени других людей.

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

Бред сивой кобылы.
Нынешние процы даже на равной частоте рвут "процы 80х" как Тузик грелку.
И да, если считать кэш узким местом, то тогда уж лучше память считать таковым.
Да ладно память, лучше диск. )