(6)
Конечно же - можно выстраивать наверное 98% всех алгоритмов на блокировках - только когда они часто ставятся, а число параллельно выполняемых операций очень велико, как и велико число физических потоков - на которых они выполняются - то блокировки сразу становятся очень узким местом. Просто это очень тяжело почувствовать на простых примерах и на небольшом числе потоков. Просто дело уже ближайшего будущего сервера с сотнями ядер на борту (а во второй половине века уже с тысячами - на которые одновременно будут в секунду поступать тысячи и десятки тысяч небольших (и больших) задач) - затраты на блокировку ресурсов станут очень велики. А программисты ещё и склонны будут неэффективно их блокировать - чрезмерно задерживая работу с ними. Это плохое решение.

А если ещё рассмотреть гетерогенные вычленения (node.js и hadoop доступны уже сейчас) - то там вообще блокировки очень нелегко ставить - это априори самое узкое место в алгоритме будет - тормозящее всё и вся!

Та же проблема в 1С и СУБД - тут слишком много чрезмерных блокировок (ну если о них заботиться при использовании управляемых блокировок; а без них и подавно)! Зачастую - алгоритмы можно было бы встроить вообще почти без длительных блокировок (даже списание по партиям) - если бы в системе были специальные асинхронные неблокирующие операции работы с ресурсами! На самом деле 1С как раз работала в этом направлении - так появились разделители (сплиттеры) и так же появилась методика контроля остатков в конце транзакции (да даже учет через расширенную аналитику - это тоже из этой же оперы) - но это всё кустарщина - но она уперается в возможности СУБД.


А вы сравните скорость работы блокировок и атомарных функций в .NET Framework - правда для тестов нужно бы взять машину с как можно большим числом ядер - какой-нибудь сервер хотя бы с 40 ядрами и стартонуть на нём сотню-другую потоков (тасков)


Кустарно на блокировках (как это предлагалось делать до .NET Framework 4) - или просто тонкие обёртки над потокобезопасными коллекциями платформы ".NET Framework"?

Кстати, ещё идея - сделать потокобезопасные переменные/свойства (ну например через атрибут "SafeThreadAttribute") - чтобы все операции над ними сразу превращались в потокобезопасные (атомарные или на крайняк с блокировкой - управлять этим должен компилятор)



(6)
Не спорю - это задача не простая - тут надо изначально под это как-то по особому язык программирования проектировать. Смысл в том - чтобы компилятору было относительно легко понять взаимосвязи между инструкциями - чтобы он их мог раскидать по потокам. Или применил известные методики распараллеливания обработки коллекций значений. Программист только должен помечать зависимости там , где ему важна заданная последовательность вычисления. Тут сама язык должен быть очень высокодекларативным - где акценты расставлены не на последовательных инструкциях, а на реальных задачах - которые нужно выполнить - без детализации способа их выполнения!

Ещё одной техникой может быть избыточная параллельность: когда в алгоритме есть много ветвлений, где вычисление условия ветвлений затратно - то можно параллельно запустить вычисление сразу нескольких ветвей и их условий - а потом уже слить вместе - по фактически вычисленному условию. Техника мощная - но чреватая: во-первых излишней нагрузкой, во-вторых - не должно быть побочных эффектов вычисления ложных ветвей, в третьих - подходит только для случая достаточно детерменированных алгоритмов (внутри ветвей); ну и вообще - это больше подходит интерпретаторам - где есть возможность проводить статистический анализ в runtime - хотя в будущем может ОС будут собирать статистику выполнения обычных программ - и оптимизировать их код при следующих запусках.


Надо это выводить статически при компиляции (как выведение типов) - но тут может быть много ошибок - у программиста должны быть средства по ручному указанию зависимостей! А так же простое средство анализа в IDE автоматически определённых зависимостей и просмотра кода - который будет выполнять параллельно (варианты представления тут могут быть различны - от цветового выделения потоков в строках кода, до формирования отдельных колонок-потоков со своими наборами инструкций и с местами их слияния).

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